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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the principles of interworking between the 3GPP IM CN subsystem and BICC/ISUP 
based legacy CS networks, in order to support IM basic voice calls. 

The present document addresses the areas of control and user plane interworking between the IM CN subsystem and CS 
networks through the network functions, which include the MGCF and IM-MGW. For the specification of control plane 
interworking, areas such as the interworking between SIP and BICC or ISUP are detailed in terms of the processes and 
protocol mappings required for the support of both IM originated and terminated voice calls. 

Other areas addressed encompass the transport protocol and signalling issues for negotiation and mapping of bearer 
capabilities and QoS information. 

The present document specifies the interworking between 3GPP profile of SIP (as detailed according to 3GPP TS 
24.229 [9]) and BICC or ISUP, as specified in ITU-T Recommendations Q.1902.1 to Q.1902.6 [30] and ITU-T Q761 to 
Q764 [4] respectively. 

The present document addresses two interworking scenarios with respect to the properties of the CS network:. 

The CS network does not use any 3GPP specific additions. 

The CS network uses 3GPP specific additions. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [6], ITU-T 
Recommendation E.164 [48] and the following apply: 

SS7 signalling function: function in the CS network, which has the capabilities to transport the SS7 MTP-User parts 
ISUP and BICC-nSTC^tp 

SIP signalling function: function in the IM CN subsystem, which has the capabilities to transport SIP 

Incoming or Outgoing: used in the present document to indicate the direction of a call (not signalling information) 
with respect to a reference point. 

Incoming MGCF (I-MGCF): entity that terminates incoming SIP calls from the IMS side and originates outgoing calls 
towards the CS side using the BICC or ISUP protocols. 

Outgoing Interworking Unit (O-MGCF): entity that terminates incoming BICC or ISUP calls from the CS side and 
originates outgoing calls towards the IMS using SIP. 
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Root Termination: refers to Media Gateway as an entity in itself, rather than a Termination within it. A special 
TerminationlD, "Root" is reserved for this purpose. See ITU-T Recommendation H.248.1. 

Signalling Transport Converter (STC): function that converts the services provided by a particular Signalling 
Transport to the services required by the Generic Signalling Transport Service. 

STCmtp: Signalling Transport Converter on MTP. See ITU-T Recommendation Q.2 150.1 [29]. 

BICCn-STCmtp: this terminology means that BICC signaling always need to be used on top of STCmtp sublayer. 



3.2 Abbreviations 

For the purposes of the present document, the abbreviations as defined in 3GPP TR 21.905 [6] and the following apply: 

ACM Address Complete Message 

ANM ANswer Message 

APRI Address Presentation Restriction Indicator 

BGCF Breakout Gateway Control Function 

BICC Bearer Independent Call Control 

CC Country Code 

CLIP Calling Line Identification Presentation 

CLIR Calling Line Identification Restriction 

CN Core Network 

COLP Connected line presentation 

COLR Connected line restriction 

CPG Call ProGress message 

CS Circuit Switched 

CSCF Call Session Control Function 

DDI Direct-Dialling-In 

GTP GPRS Tunneling Protocol 

H/W Hardware 

IP Internet Protocol 

IM-MGW IP Multimedia Media Gateway Function 

ISDN Integrated Services Data Network 

ISUP Integrated Services User Part 

M3UA MTP-L3 User Adaptation layer 

MGCF Media Gateway Control Function 

MGW Media Gateway 

MSN Multiple Subscriber Number 

MTP Message Transfer Part 

NDC National Destination Code 

NOA Nature Of Address 

PLMN GSM Public Land Mobile Network 

SCTP Stream Control Transmission Protocol 

SDP Session Description Protocol 

SGW Signalling Gateway 

SIP Session Initiated Protocol 

SN Subscriber Number 

SS7 SignalHng System No. 7 

TNL Transport Network Layer 

UAC User Agent Client 

UE User Equipment 

URL Uniform Resource Location 
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4 General 

4.1 General interworking overview 

The IM CN subsystem shall interwork with BICC and ISUP based legacy CS networks, e.g. PSTN, ISDN, CS PLMNs, 
in order to provide the ability to support basic voice calls (see 3GPP TS 22.228 [11]), between a UE located in the IM 
CN subsystem and user equipment located in a CS network. 

For the ability to support the delivery of basic voice calls between the IM CN subsystem and CS networks, basic 
protocol interworking between SIP (as specified in 3GPP TS 24.229 [9]) and BICC or ISUP (as specified in ITU-T 
Recommendations Q. 1902. 1-6 [30] and ITU-T Recommendations Q761 to Q764 [4] respectively) has to occur at a 
control plane level, in order that call setup, call maintenance and call release procedures can be supported. The MGCF 
shall provide this protocol mapping functionality within the IM CN subsystem. 

User plane interworking between the IM CN subsystem and CS network bearers (e.g. 64k TDM, ATM/AAL2 circuit or 
IP bearer) are supported by the functions within the IM-MGW. The IM-MGW resides in the IM CN subsystem and 
shall provide the bearer channel interconnection. The MGCF shall provide the call control to bearer setup association. 

The IM CN subsystem shall interwork, at the control and user plane, with BICC and ISUP based legacy CS networks. 
The support of supplementary services shall be as defined in 3GPP TS 22.228 [11]. The MGCF and IMS-MGW shall 
support the interworking of the IM CN subsystem to an external ISUP based CS network. They may also support 
interworking to a BICC based CS network where no 3GPP specific extension is applied. The MGCF and the IM-MGW 
may also support interworking to a BICC based CS network where 3GPP specific extensions in accordance with 3GPP 
TS 29.205 [14] are applied. 



5 Network characteristics 

5.1 Key characteristics of ISUP/BICC based CS networks 

This signalling interface to a PSTN is either based on BICC Capability Set 2 as specified in ITU-T Recommendations 
Q.1902.1 to Q.1902.6 [30], or on ISUP (see ITU-T Recommendations Q.761 to Q.764 [4]). 

The interface towards a CS-PLMN may either be one of the interfaces mentioned in the paragraph above or a signalling 
interface based on BICC with 3GPP specific extensions, as specified for the 3GPP Nc interface in 3GPP TS 29.205 
[14], and the IM-MGW may support the 3GPP Nb interface, as specified in 3GPP TS 29.414 [25] and 3GPP TS 29.415 
[26]. If the 3GPP Nc interface is applied as signalling interface, the 3GPP Nb interface is used as user plane interface 
and the Nb UP Framing protocol is applied. 

5.2 Key characteristics of IM CN subsystem 

The IM CN subsystem uses SIP to manage IP multimedia sessions in a 3GPP environment, it also uses IPv6, as defined 
in RFC 2460 [39], as the transport mechanism for both SIP session signalling and media transport. The 3GPP profile of 
SIP defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [9]. Example callflows are 
provided in 3GPP TS 24.228 [8]. 



6 Interworking with CS networks 

6.1 Interworking reference model 

Figure 1 details the reference model required to support interworking between the 3GPP IM CN subsystem and CS 
networks for IM basic voice calls. 
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NOTE 1 : The logical split of the signalling and bearer path between the CS network and the IIVI CN subsystem is as 

shown, however the signalling and bearer may be logically directly connected to the IIVI-MGW. 
NOTE 2: The SGW may be implemented as a stand-alone entity or it may be located in another entity either in the 

CS network or the IIVI-MGW. The implementation options are not discussed in the present document. 
NOTE 3: The IIVI-MGW may be connected via the Mb to various network entities, such as a UE (via a GTP Tunnel to 

a GGSN), an MRFP, or an application server. 
NOTE 4: A SGW function is not required for certain signalling transports, where M3UA-kSGTP-hIP is used in OS 

network and IM-MGCF. 

Figure 1 : IM CN subsystem to CS network logical interworking reference model 

6.1 .1 Interworking reference points and interfaces 

The reference points and network interfaces shown in figure 1 are as described: 

Protocol for Mg reference point: The single call control protocol applied across the Mg reference point (i.e. between 
CSCF and MGCF) will be based on the 3GPP profile of SIP as defined in accordance with 3GPP TS 24.229 [9]. 

Protocol for Mn reference point: The Mn reference point describes the interfaces between the MGCF and IM-MGW, 
and has the properties as detailed in 3GPP TS 29.332 [15]. 

Protocol for Mj reference point: The single call control protocol applied across the Mj reference point (i.e. between 
BGCF and MGCF) will be based on the 3GPP profile of SIP as defined in accordance with 3GPP TS 24.229 [9]. 

Protocol for Mb reference point: The Mb reference point is defined in accordance with 3GPP TS 23.002 [10] and is 
IPv6 based. 

6.1 .2 Interworking functional entities 



6.1.2.1 



Signalling Gateway Function (SGW) 



This component performs the call related signalling conversion to or from BICC/ISUP based MTP transport networks 
to BICC/ISUP based SCTP/IP transport networks, and forwards the converted signalling to or from the MGCF. The 
functionahty within SGW shall be in accordance with 3GPP TS 23.002 [10]. 



6.1.2.2 



Media Gateway Control Function (MGCF) 



This is the component within the IM CN subsystem, which controls the IM-MGW, and also performs SIP to BICC or 
SIP to ISUP call related signalling interworking. 

The functionality defined within MGCF shall be defined in accordance with 3GPP TS 23.002 [10]. 



£75/ 



3GPP TS 29.1 63 version 6.1 2.0 Release 6 1 7 ETSI TS 1 29 1 63 V6.1 2.0 (2009-06) 

6.1 .2.3 IP Multimedia - Media Gateway Function (IM-MGW) 

This is the component within the IM CN subsystem, which provides the interface between the PS domain and the CS 
domain, and it shall support the functions as defined in accordance with 3GPP TS 23.002 [10]. 

6.2 Control plane interworking model 

Within the IM CN subsystem, the 3GPP profile of SIP is used to originate and terminate IM sessions to and from the 
UE. 

External CS networks use BICC or ISUP to originate and terminate voice calls to and from the IM CN subsystem. 

Therefore, in order to provide the required interworking to enable inter network session control, the control plane 
protocols shall be interworked within the IM CN subsystem. This function is performed within the MGCF (see clause 
6.1.2). 

6.3 User plane interworking model 

Within the IM CN subsystem, IPv6, and framing protocols such as RTP, are used to transport media packets to and 
from the IM CN subsystem entity like UE or MRFP. 

External legacy CS networks use circuit switched bearer channels like TDM circuits (e.g. 64 kbits PCM), ATM/AAL2 
circuit or IP bearers to carry encoded voice frames, to and from the IM CN subsystem. 

Other CN networks use ATM/A AL 1 or AAL 2 or IP as a backbone, with different framing protocols. 

Therefore, in order to provide the required interworking to enable media data exchange, the user plane protocols shall 
be translated within the IM CN subsystem. This function is performed within the IM-MGW (see clause 6.1.2). 



7 Control plane interworking 



Signalling from CS networks to or from IM CN subsystem, where the associated supported signalling protocols are 
SS7/M3UA+ SCTP+IP and M3UA+SCTP+IP respectively, requires a level of interworking between the nodes across 
the Control Plane, i.e. the SS7 signalling function, SGW (if applicable), MGCF and SIP signalling function. This 
interworking is required in order to provide a seamless support of a user part, i.e. SIP and BICC+STCmtp or SIP and 
ISUP. 

The transport of SS7 signalling protocol messages of any protocol layer that is identified by MTP level 3, in SS7 terms, 
as a user part (MTP3-user) shall be accomplished in accordance with the protocol architecture defined in the following 
clauses. For the present document these protocol layers include, but are not limited to. Bearer Independent Call Control 
(BICC)+STC„,p and ISDN User Part (ISUP). 

7.1 General 

The following sub-clauses define the signalling interworking between the Bearer Independent Call Control (BICC) or 
ISDN User Part (ISUP) protocols and Session Initiation Protocol (SIP) with its associated Session Description Protocol 
(SDP) at a MGCF. The MGCF shall act as a Type A exchange (ITU-T Recommendation Q.764 [4]) for the purposes of 
ISUP and BICC Compatibility procedures. The services that can be supported through the use of the signalling 
interworking are limited to the services that are supported by BICC or ISUP and SIP based network domains. 

BICC is the call control protocol used between Nodes in a network that incorporates separate call and bearer control. 
The BICC/ISUP capabilities or signalling information defined for national use is outside the scope of the present 
document. It does not imply interworking for national-specific capabilities is not feasible. 

The capabihties of SIP and SDP that are interworked with BICC or ISUP are defined in 3GPP TS 24.229 [9] 

Services that are common in SIP and BICC or ISUP network domains will seamlessly interwork by using the function 
of the MGCF. The MGCF will originate and/or terminate services or capabilities that do not interwork seamlessly 
across domains according to the relevant protocol recommendation or specification. 
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Table 1 lists the services seamlessly interworked and therefore within the scope of the present document. 
Table 1 : Interworking Capabilities between BICC/ISUP and SIP profile for 3GPP 



Service 



Speech/3.1 kHz audio 

En bloc address signalling 

Overlap address signalling from the CS side towards the IMS 

Out of band transport of DTMF tones and information. (BICC only) 

Inband transport of DTMF tones and information. (BICC and ISUP) 

Direct-Dialling-ln (DDI) 

Multiple Subscriber Number (MSN) 

Calling Line Identification Presentation (CLIP) 

Calling Line Identification Restriction (CLIR) 

Connected line presentation (COLP) 

Connected line restriction (COLR) 



7.2 Interworking between CS networks supporting ISUP and 
the IM CN subsystem 

The control plane between CS networks supporting ISUP and the IM CN subsystem supporting SIP, where the 
underlying network is SS7 and IP respectively is as shown in figure 2. 
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Figure 2: Control plane interworking between CS networks supporting ISUP 

and the IM CN subsystem 

7.2.1 Services performed by network entities in tine control plane 



7.2.1.1 



Services performed by the 887 signalling function 



The SS7 signalling function provides the capabilities to deliver or receive SS7 MTP3-User information (e.g. ISUP or 
BICC+STCmtp) across the SS7 signalling network. The functional interface of the MTP, the MTP User parts and the 
signalling network are as detailed in ITU-T Recommendations Q.701 to Q.709 [3]. 
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7.2.1.2 Services of the SGW 

The SGW shall perform the functions as described in 3GPP TS 23.002 [10]. 

In order to support the seamless operation of the MTP3-User part information between networks incorporating SS7 and 
IP (either IPv4, see RFC 791 [16], or IPv6, see RFC 2460 [39]), the SGW shall support the services of MTP as well as 
the services of the M3UA (see 3GPP TS 29.202 [20]) and SCTP (see RFC 2960 [18]). 

7.2.1 .3 Services of the MGCF 

The session handling and session control of the MGCF shall be as detailed in 3GPP TS 24.229 [9]. 

The MGCF shall provide the interaction, through the use of its interworking function, between the SS7 MTP3-User part 
information, e.g. ISUP, and SIP. It shall also provide the interaction between the mechanism used to transport the SS7 
MTP3-User part information and SIP, i.e. the interaction between M3UA and SCTP and UDP/TCP (see RFC 768 [17] 
and RFC 793 [24]). 

The MGCF interworking function shall also provide the translation between the SS7 MTP3-User part information and 
SIP, where the interworking of SIP to ISUP and BICC+STCmtp are detailed below. 

7.2.1 .4 Services of the SIP signalling function 

The SIP signalling function is a logical entity that provides the capabilities to deliver or receive multimedia session 
information across the IM CN subsystem signalling system. 

7.2.2 Signalling interactions between network entities in the control plane 
7.2.2.1 Signalling between the SS7 signalling function and MGCF 

The SGW shall enable the signalling interaction between the SS7 signalling function and the MGCF. 

7.2.2.1 .1 Signalling from MGCF to SS7 signalling function 

For signalling from the MGCF to the SS7 signalling function, the SGW shall terminate the SCTP and M3UA protocol 
layers and deliver the MTP3-User protocol messages, e.g. ISUP messages, towards the SS7 signalling function. The 
SGW transmits and receives SS7 Message Signalling Units (MSUs) to and from the SS7 signalling function over 
standard SS7 network interfaces, using MTP to provide reliable transport of the messages. 

7.2.2.1 .2 Signalling from SS7 signalling function to MGCF 

For signalling from the SS7 signalling function to the MGCF, the SGW shall terminate SS7 MTP2 and MTP3 protocol 
layers and deliver MTP3-User part information messages, e.g. ISUP, towards the MGCF. In order to direct messages 
received from the SS7 MTP3 network to the appropriate IP destination, e.g. MGCF, the SGW shall perform a message 
distribution function using the information received from the MTP3-User message. Message distribution at the SGW 
shall be performed in accordance with 3GPP TS 29.202 [20]. 

7.2.2.1 .3 Services offered by SCTP and M3UA 

The SGW internal protocol mapping and transportation between BICC or ISUP messages and IP encapsulated BICC or 
ISUP messages respectively is supported by the services of the M3UA adaptation layer and the underlying SCTP layer. 
The SGW shall allow for the transfer of MTP3-User signalling messages, e.g. BICC or ISUP, to and from an MGCF, 
where the peer MTP3-User protocol exists. 

7.2.2. 1.3.1 Services offered by SCTP 

SCTP offers the ability to reUably transfer the SCTP User applications, e.g. M3UA, between the SCTP User application 
peers. The initialization procedure used for an association between two SCTP end-to-end peers, and the initialization to 
the SCTP User applications shall be performed as detailed in RCF 2960 [18]. 
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7.2.2.1.3.2 



Services offered by M3UA 



When an association between two SCTP peers has been established, the use of M3UA shall provide the transport 
service in accordance with MTP (see ITU-T Recommendations Q.701 to Q.709 [3]) to the MTP3-User, e.g. ISUP. 



7.2.2.2 



Signalling between the IVIGCF and SIP signalling function 



Signalling between the SIP signalling function and the MGCF uses the services of IP (RFC 2460 [39]), TCP (RFC 793 
[24]) or UDP (RFC 768 [17]) and SIP. 

The naming and addressing concepts between the MGCF and SIP signalling function shall be detailed in accordance 
with 3GPP TS 23.228 [12]. The issues of general IP address management are discussed in 3GPP TS 23.221 [47]. 

7.2.3 SIP-ISUP protocol interworking 

When a coding of a parameter value is omitted it implies that it is not affected by the interworking and the values are 
assigned by normal protocol procedures. 



7.2.3.1 



Incoming call interworking from SIP to ISUP at l-MGCF 



7.2.3.1.1 



Sending of lAM 



On reception of a SIP INVITE requesting an audio session, the I-MGCF shall send an lAM message. 

The I-MGCF shall interwork forked INVITE requests with different request URIs. 

If a Continuity Check procedure is supported in the ISUP network, the I-MGCF shall send the lAM immediately after 
the reception of the INVITE, as shown in figure 3. This procedure applies when the value of the continuity indicator is 
either set to "continuity check required' or "continuity check performed on a previous circuit". If the continuity indicator 
is set to "continuity check required" the corresponding procedures at the Mn interface described in clause 9.2.2.3 also 
apply. 

I-MGCF 



INVITE 



lAM 



Figure 3: Receipt of an Invite request (continuity procedure supported in the ISUP network) 

If no Continuity Check procedure is supported in the ISUP network, the I-MGCF shall delay sending the lAM until the 
SIP preconditions are met. 

I-MGCF 



INVITE 



lAM 



SDP indicating 

pre-conditions 

met 



Figure 4: Receipt of an Invite request (continuity procedure not supported in the ISUP network) 
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The I-MGCF shall reject an INVITE request for a non-audio session by sending a status code 488 "Not Acceptable 
Here". If audio media streams and non-audio media streams are contained in a single INVITE request, the non-audio 
media streams shall be rejected in the SDP answer, as detailed in RFC 3264 [36]. 

The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early 
dialog as described in RFC 3261 [19]. 



7.2.3.1.2 Coding of the lAM 

The following ISDN user part parameters description can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.1.2.1 Called party number 

The E.164 address encoded in the Request-URI shall be mapped to the called party number parameter of the lAM 
message. 

Table 2: Coding of the called party number 



INVITE^ 


lAM^ 


Request-URI 


Called Party Number 


E.164 address 

(e.g. as User info in SIP URI with 

user=phone, or as tel URL) 


Address Signal 



7.2.3.1 .2.2 Nature of connection indicators 
bits BA Satellite indicator 

1 one satellite circuit in the connection 

bits DCContinuity check indicator 

continuity check not required) if the continuity check procedure is not supported in the succeeding network 
(figure 4). 

1 continuity check required, if a continuity check shall be carried out on the succeeding circuit, (figure 3) 

1 continuity check performed on a previous circuit otherwise, if the continuity check procedure is supported 
in the succeeding network, but shall not be carried out on the succeeding circuit otherwise, (figure 3) 

bit E Echo control device indicator 

1 outgoing echo control device included 

7.2.3.1.2.3 Forward call indicators 
bits CB End-to-end method indicator 

no end-to-end method available (only link-by-link method available) 
bit D Interworking indicator 

1 interworking encountered 

bit E End-to-end information indicator (national use) 

no end-to-end information available 
bit F ISDN user part/BICC indicator 
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ISDN user part/BICC not used all the way 
bits HG ISDN user part/BICC preference indicator 

1 ISDN user part/BICC not required all the way 
bit I ISDN access indicator 

originating access non-ISDN 
bits KJ SCCP method indicator 

no indication 



7.2.3.1.2.4 



Calling party's category 



00001010 



ordinary calling subscriber 



7.2.3.1.2.5 Transmission medium requirement 

The TMR parameter is set to "3.1 kHz audio" or "speech". 



7.2.3.1.2.6 



Calling party number 



The SIP "Privacy" header is defined within RFC 3323 [40]. The SIP "P-Asserted-Identity" header is defined in RFC 

3325 [41]. 
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Table 3: Mapping of SIP From/P-Asserted-ldentity/Privacy headers to CLI parameters 



Has a "P-Asserted- 

Identity" header 

field (note 2, note 5, 

note 6) been 

received? 


Has a "From" 

header field 

(note 3) 

containing a URI 

that encodes an 

E.1 64 address 

been received 

(note 6)? 


Calling Party 

Number parameter 

Address signals 


Calling Party 

Number 

parameter 

APRI 


Generic 
Number 
(additional 
calling party 
number) 
address 
signals 


Generic 

Number 

parameter 

APRI 


No 


No 


Network option to 
either include a 
network provided 
E.1 64 number (See 
table 4) or omit the 
Address signals, (note 
4) 


Network 
option to set 
APRI to 
'presentation 
restricted' or 
'presentation 
allowed' 
(note 4) 
(See table 5) 


Parameter not 
included 


Not 
applicable 


No 


Yes 


Network Option to 
either include a 
network provided 
E.1 64 number (See 
table 4) or omit the 
Address signals, (note 
4) 


Network 
option to set 
APRI to 
'presentation 
restricted' or 
'presentation 
allowed' 
(note 4) 
(See table 5) 


Network 
Option to 
either omit the 
parameter (if 
CgPN has 
been omitted) 
or derive from 
the 'From' 
header (note 

1) 

(See table 6) 


APRI = 
'presentation 
restricted' or 
'presentation 
allowed' 
depending on 
SIP Privacy 
header. 
(See table 6) 


Yes 


No 


Derive from 
P-Asserted-ldentity 
(See table 5) 


APRI = 
'presentation 
restricted' or 
'presentation 
allowed' 
depending on 
SIP Privacy 
header. 
(See table 5) 


Not included 


Not 
applicable 


Yes 


Yes 


Derived from 
P-Asserted-ldentity 
(See table 5) 


APRI = 
'presentation 
restricted' or 
'presentation 
allowed' 
depending on 
SIP Privacy 
header. 
(See table 5) 


Network 
Option to 
either omit the 
parameter or 
derive from the 
'From' header 
(note 1) 
(See table 6) 


APRI = 
'presentation 
restricted' or 
'presentation 
allowed' 
depending on 
SIP Privacy 
header, 
(see table 6) 


Note 1 : This mapping effectively gives the equivalent of Special Arrangement to all SIP UAC with access to the 

l-IVIGCF. 
Note 2: It is possible that the P-Asserted-ldentity header field includes both a tel URL and a sip or sips URI. In this 

case, the tel URL is used. 
Note 3: The 'From' header may contain an 'Anonymous URI'. An 'Anonymous URI' includes information that does not 

point to the calling party. RFC 3261 recommends that the display-name component contain "Anonymous". 

RFC 3323 [40] recommends that the Anonymous URI itself have the value 

"anonymous@anonymous. invalid". 
Note 4: A national option exists to set the APRI to 'Address not available'. 
Note 5: 3GPP TS 24.229 guarantees that the received number is an E.1 64 number formatted as an international 

number, with a '+' sign as prefix. 
Note 6: The E.1 64 numbers considered within the present document are composed by a Country Code (CC), 

followed by a National Destination Code (NDC) , followed by a Subscriber Number (SN). On the IIVIS side, 

the numbers are international public telecommunication numbers ('CC'+'NDC'+'SN') and are prefixed by a '+' 

sign. On the CS side, it is a network option to omit the CC. 
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Table 4: Setting of the network-provided BICC/ISUP calling party number parameter with a CLI 

(network option) 



BICC/ISUP CgPN Parameter field 


Value 


Screening Indicator 


"networl< provided" 


Number Incomplete Indicator 


"complete" 


Number Plan Indicator 


ISDN/Telephony (E. 164) 


Address Presentation Restricted 
Indicator 


Presentation allowed/restricted 


Nature of Address Indicator 


If next BICC/ISUP node is located in the same 
country set to 'National (Significant) number" 
else set to "International number" 


Address signals 


If NOA is "national (significant) number" no 
country code should be included. If NOA is 
"international number", then the country code 
of the network-provided number should be 
included. 



Table 5: Mapping of P-Asserted-ldentity and privacy headers to the ISUP/BICC calling party number 

parameter 



SIP Component 


Value 


BICC/ISUP Parameter / field 


Value 


P-Asserted-ldentity 
header field (note 1) 


E.164 number 


Calling Party Number 






Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E. 164)" 


Nature of Address Indicator 


If CC encoded in the 
URI is equal to the CC of 
the country where MGCF 
is located AND the next 
BICC/ISUP node is located 
in the same country then 
set to "national (significant) 
number" 

else set to "international 
number" 


Address Presentation Restricted 
Indicator (APRI) 


Depends on priv-value in 
Privacy header. 


Screening indicator 


Network Provided 


Addr-spec 


"CC" "NDC" "SN" from 
the URI 


Address signal 


if NOA is "national 

(significant) number" \her\ 

set to 

"NDC" + "SN" 

If NOA is 'international 

number" 

Then set to "CC"-^" 

NDC"+"SN" 


Privacy header field is 
not present 




APRI 


Presentation allowed 


Privacy header field 


priv-value 


APRI 


"Address Presentation 
Restricted Indicator" 


priv-value 


"header" 


APRI 


Presentation restricted 


"user" 


APRI 


Presentation restricted 


"none" 


APRI 


Presentation allowed 


"id" 


APRI 


Presentation restricted 


Note 1 : It is possible that a P-Asserted -Identity header field includes both a TEL URI and a SIP or SIPS URI. 
In this case, the TEL URL is used. 
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7.2.3.1.2.7 



Generic number 



Table 6: Mapping of SIP from header field to BICC/ISUP generic number (additional calling party 

number) parameter (network option) 



SIP component 


Value 


BICC/ISUP parameter / field 


Value 


From header field 


name-addr or addr-spec 


Generic Number 
Number Qualifier Indicator 


"Additional Caliing Party 
number" 


from-spec 


{ name-addr / addr- 
spec) 








Nature of Address Indicator 


If CC encoded in tine 
URI is equal to the CC of 
the country where IVIGCF is 
located AND the next 
BICC/ISUP node is located 
in the same country then 
Set to "nationai (significant) 
number" 

Else set to "internationai 
number" 


Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E. 164)" 


APRI 


Depends on priv-value 


Screening indicator 


"user provided not verified" 


Addr-spec 


"CC" "NDC" + "SN" from 
the URI 


Address signal 


if NOA is "national 

(significant) number" \.her\ 

set to 

"NDC" + "SN" 

If NOA is "international 

number" 

Then set to "CC"-i-' 

NDC'-h'SN' 


Privacy header field 


priv-value 


APRI 


"Address Presentation 
Restricted Indicator" 


Use same APR! setting as for Calling Party Number. 



7.2.3.1.2.8 User service information 

The Information Transfer Capability Information element is coded as 'speech' or "3.1 kHz audio". 



7.2.3.1.2.9 



Hop Counter (National option) 



The I-MGCF shall perform the following interworking procedure if the Hop Counter procedure is supported in the CS 
network. 

At the I-MGCF the Max-Forwards SIP header shall be used to derive the Hop Counter parameter if applicable. Due to 
the different default values (that are based on network demands/provisions) of the SIP Max-Forwards header and the 
Hop Counter, a factor shall be used to adapt the Max Forwards to the Hop Counter at the I-MGCF. For example, the 
following guidelines could be applied. 

1) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP entity, 
regardless of intervening interworking, and similarly for Hop Counter. 

2) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the 
maximum number of hops that may be expected of a validly routed call. 

Table 7 shows the principle of the mapping: 

Table 7: Max forwards - hop counter 



Max-Forwards 



X 



Hop Counter 



INTEGER part of (X /Factor) =Y 



Note: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism. 



£75/ 



3GPP TS 29.163 version 6.12.0 Release 6 



26 



ETSI TS 129 163 V6.12.0 (2009-06) 



The Principle of adoption could be implemented on a basis of the network provision, trust domain rules and bilateral 
agreement. 



7.2.3.1.3 



Sending of COT 



SDP indicating 
pre-conditions 
met 



I-MGCF 

— ► 



COT 



Figure 5: Sending of COT 

If the lAM has already been sent, the Continuity message shall be sent indicating "continuity check successful", when 
all of the following conditions have been met: 

the requested preconditions in the IMS network have been met 

A possible outstanding continuity check procedure is successfully performed on the outgoing circuit 



7.2.3.1 .4 Sending of 1 80 ringing 

The I-MGCF shall send the SIP 180 Ringing when receiving any of the following messages: 
ACM with Called party's status indicator set to subscriber free. 



I-MGCF 



180 Ringing 



ACM 
(Subscriber Free) 



Figure 6: Thie receipt of ACIUI 



CPG with Event indicator set to alerting 



I-MGCF 



180 (Ringing) 



CPG (Alerting) 



Figure 7: Receipt of CPG (Alerting) 
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7.2.3.1 .5 Sending of the 200 OK (INVITE) 

The following cases are possible trigger conditions for sending the 200 OK (INVITE): 
The reception of the ANM. 

I-MGCF 



200 OK (INVITE) 


^ 


ANM 


^ 


^ 




^ 





The reception of the CON message. 



Figure 8: Receipt of ANIV! 



I-MGCF 



200 OK (INVITE) 


^ 


CON 


^ 


^ 




^ 





Figure 9: Receipt of CON 

7.2.3.1 .6 Sending of the Release message (REL) 

The following are possible triggers for sending the Release message: 
Receipt of the BYE method. 



I-MGCF 



BYE 



REL 



Figure 10: Receipt of the Bye method 

Receipt of the CANCEL method 



I-MGCF 



CANCEL 



REL 



Figure 1 1 : Receipt of Cancel method 

Additional triggers are contained in table 10. 
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7.2.3.1.7 



Coding of the REL 



The SIP BYE and CANCEL requests are mapped into a REL message with cause value #16 and #31 respectively as 
indicated in table 8. 

Table 8: Coding of REL 



SIP Message -> 


REL-^ 


Request 


cause parameter 


BYE 


Cause value No. 16 (normal clearing) 


CANCEL 


Cause value No. 31 (normal unspecified) 



NOTE: If an optional Reason header field is included in the BYE or CANCEL, then the Cause Value can be 
mapped to the ISUP Cause Value field in the ISUP REL. The mapping between the Cause Indicators 
parameter and the Reason header is out of the scope of the present specification. 



7.2.3.1.8 



Receipt of the Release Message 



If the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall 
send a BYE message. 

NOTE: According to SIP procedures, in the case that the REL message is received and a final response (e.g. 200 
OK (INVITE)) has already been sent (but no ACK has been received) on the incoming side of the I- 
MGCF then the I- MGCF does not send a 487 Request terminated and instead waits until the ACK is 
received before sending a BYE message. 

If the REL message is received and the final response (i.e. 200 OK (INVITE)) has not already been sent, the I- MGCF 
shall send Status-Code 4xx (Client Error) or 5xx (Server Error). The Status code to be sent is determined by examining 
the Cause code value received in the REL message. Table 9 specifies the mapping of the cause code values, as defined 
in ITU-T Recommendation Q.850 [38], to SIP response status codes. Cause code values not appearing in the table shall 
have the same mapping as the appropriate class defaults according to ITU-T Recommendation Q.850 [38]. 

Table 9: Receipt of the Release message (REL) 



<-SIP Message 


<-REL 


Status code 


Cause parameter 


404 Not Found 


Cause value No. 1 (unallocated (unassigned) number) 


500 Server Internal error 


Cause value No 2 (no route to network) 


500 Server Internal error 


Cause value No 3 (no route to destination) 


500 Server Internal error 


Cause value No. 4 (Send special information tone) 


404 Not Found 


Cause value No. 5 (Misdialled trunk prefix) 


486 Busy Here 


Cause value No. 17 (user busy) 


480 Temporarily 
unavailable 


Cause value No 18 (no user responding) 


480 Temporarily 
unavailable 


Cause value No 19 (no answer from the user) 


480 Temporarily 
unavailable 


Cause value No. 20 (subscriber absent) 


480Temporarily 
unavailable 


Cause value No 21 (call rejected) 


410 Gone 


Cause value No 22 (number changed) 


480 Temporarily 
unavailable 


Cause value No 25 (Exchange routing error) 


502 Bad Gateway 


Cause value No 27 (destination out of order) 


484 Address Incomplete 


Cause value No. 28 invalid number format (address incomplete) 
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<-SIP Message 


<-REL 


Status code 


Cause parameter 


500 Server Internal error 


Cause value No 29 (facility rejected) 


480 Temporarily 
unavailable 


Cause value No 31 (normal unspecified) (class default) (Note 1) 


486 Busy here if 

Diagnostics indicator 

includes the (CCBS 

indicator = CCBS 

possible) 

else 480 Temporarily 

unavailable 


Cause value in the Class 010 (resource unavailable, Cause value No 34) 


500 Server Internal error 


Cause value in the Class 01 
(resource unavailable, Cause value No"s. 38, 41 , 42, 43, 44, & 47) (47 is 

class default) 


500 Server Internal error 


Cause value No 50 (requested facility no subscribed) 


500 Server Internal error 


Cause value No 57 (bearer capability not authorised) 


500 Server Internal error 


Cause value No 58 (bearer capability not presently) 


500 Server Internal error 


Cause value No 63 (service option not available, unspecified) 
(class default) 


500 Server Internal error 


Cause value in the Class 100 (service or option not implemented, Cause 
value No"s. 65, 70 & 79) 79 is class default 


500 Server Internal error 


Cause value No 88 (incompatible destination) 


404 Not Found 


Cause value No 91 (invalid transit network selection) 


500 Server Internal error 


Cause value No 95 (invalid message) 
(class default) 


500 Server Internal error 


Cause value No 97 (Message type non-existent or not implemented) 


500 Server Internal error 


Cause value No 99 (information element/parameter non-existent or not 

implemented)) 


480 Temporarily 
unavailable 


Cause value No. 102 (recovery on timer expiry) 


500 Server Internal error 


Cause value No 1 10 (Message with unrecognised Parameter, discarded) 


500 Server Internal error 


Cause value No. 1 1 1 (protocol error, unspecified) 
(class default) 


480 Temporarily 
unavailable 


Cause value No. 127 (interworking unspecified) 
(class default) 


NOTE 1 : Class 1 and class 2 have the same default value. 



7.2.3.1.9 



Receipt of RSC, GRS or CGB (H/W oriented) 



If a RSC, GRS or CGB (HAV oriented) message is received after an initial address message has been sent for that 
circuit and after at least one backward message relating to that call has been received then: 

1) If the final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall send a BYE message. 

2) If the final response (i.e. 200 OK (INVITE)) has not already been sent, the I-MGCF shall send a SIP response 
with Status-Code 480 Temporarily Unavailable. 



7.2.3.1.10 



Autonomous Release at I-MGCF 



Table 10 shows the trigger events at the MGCF and the release initiated by the MGCF when the call is traversing from 
SIP to ISUP/BICC. 
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Table 10: Autonomous Release at l-MGCF 



^SIP 


Trigger event 


REL^ 
cause parameter 


Response 


484 Address Incomplete 


Determination that insufficient 
digits received. 


Not sent. 


480 Temporarily 
Unavailable 


Congestion at the MGCF/Call 
is not routable. 


Not sent. 


BYE 


ISUP/BICC procedures result 
in release after answer 


According to ISUP/BICC 
procedures. 


BYE 


SIP procedures result in 
release after answer. 


127 (Interworking 
unspecified) 


500 Server Internal error 


Call release due to the 

ISUP/BICC compatibility 

procedure (note) 


According to ISUP/BICC 
procedures. 


484 Address Incomplete 


Call release due to expiry of 

T7 within the ISUP/BICC 

procedures 


According to ISUP/BICC 
procedures. 


480 Temporarily 
Unavailable 


Call release due to expiry of 

T9 within the BICC/ISUP 

procedures 


According to BICC/ISUP 
procedures. 


480 Temporarily 
Unavailable. 


Other BICC/ISUP procedures 

result in release before 

answer. 


According to BICC/ISUP 
procedures. 


NOTE: IVIGCF receives unrecognized ISUP or BICC signalling information and 
determines that the call needs to be released based on the coding of the 
compatibility indicators, refer to ITU-T Recommendation Q.764 [4] and ITU- 
TQ.1 902.4 [30]. 



7.2.3.1 .1 1 Internal through connection of the bearer path 

The through connection procedure is described in clause subclauses 9.2.3.1.7 and 9.2.3.2.7. 

7.2.3.2 Outgoing Call Interworking from ISUP to SIP at 0-MGCF 

7.2.3.2.1 Sending of INVITE 



0-MGCF 



lAM 



INVITE 



Figure 12: Receipt of an lAM (En bloc signalling in CS network) 



0-MGCF 



lAM 


k. 


INVITE 




SAM 








w 


► 



Figure 13: Receipt of an lAM (Overlap signalling in CS network) 
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After initiating the normal incoming BICC/ISUP call establishment procedures, determining the end of address 
signalling and selecting to route the call to the IMS domain, the O-MGCF shall send the initial INVITE with pre- 
conditions. Only calls with Transmission Requirements of speech or 3.1 kHz audio will be routed to the IMS domain, 
all other types of call attempts will be rejected. 

The end of address signalling shall be determined by the earlier of the following criteria: 

a) by receipt of an end-of -pulsing (ST) signal; or 

b) by receipt of the maximum number of digits used in the national numbering plan; or 

c) by analysis of the called party number to indicate that a sufficient number of digits has been received to route 
the call to the called party; or 

d) by observing that timer Ti/wl has expired after the receipt of the latest address message and the minimum 
number of digits required for routing the call have been received. 



If the end of the address signalling is determined in accordance with criteria a) b) or c), the timer Ti/w2 is started when 
INVITE is sent. 



7.2.3.2.2 



Coding of the INVITE 



7.2.3.2.2.1 



REQUEST URI Header 



The called party number parameter of the lAM message is used to derive Request URI of the INVITE Request. The 
Request URI is a tel URL and shall contain an International public telecommunication number prefixed by a "+" sign 
(e.g. tel:H-4911231234567). 



7.2.3.2.2.2 



SDP Media Description 



Depending on the coding of the continuity indicators different precondition information (RFC 3312 [37]) is included. If 
the continuity indicator indicates "continuity performed on a previous circuit" or "continuity required on this circuit", 
then the O-MGCF shall indicate that the precondition is not met. Otherwise the MGCF shall indicate whether the 
precondition is met, dependent on the possibly applied resource reservation within the IMS. 

The SDP media description will contain precondition information as per RFC 3312 [37]. 

The O-MGCF shall include the AMR codec transported according to RFC 3267 [23] with the options listed in clause 
5.1.1 of 3GPP TS 26.236 [32] in the SDP offer. Within the SDP offer, the O-MGCF should also provide SDP RR and 
RS bandwidth modifiers specified in IETF RFC 3556 [59] to disable RTCP, as detailed in Clause 7.4 of 3GPP TS 
26.236 [32]. 

Table 1 1 provides a summary of how the header fields within the outgoing INVITE message are populated. 

Table 11 - Interworked contents of the INVITE message 



lAM^ 


INVITE^ 


Called Party Number 


Request-URI 


Calling Party Number 


P-Asserted-ldentity 


Privacy 


From 


Generic Number {"additional calling party number') 


From 


Hop Counter 


Max-Forwards 


TMR/USI 


Message Body (application/SDP) 
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7.2.3.2.2.3 



P-Asserted-ldentity, From and Privacy header fields 



Table 12: Mapping BICC/ISUP CLI parameters to SIP header fields 



Has a Calling Party 

Number parameter 

with complete E.164 

number, with 

Screening Indicator 

= UPVP or NP (See 

note 1), and with 

APRI = 

"presentation 

allowed" or 

"presentation 

restricted" been 

received? 


Has a Generic 

Number (additional 

calling party 

number) with a 

complete E.164 

number, with 

Screening Indicator 

= UPNV, and with 

APRI = 

"presentation 

allowed" been 

received? 


P-Asserted-ldentity 
header field 


From header field: 


Privacy header field 


N 


N 


Header field not 
included 


SIP or SIPS URI with 
addr spec 

"unavailable@anony 
mous. invalid" (note 2) 


Header field not 
included 


N (Note 3) 


Y 


Header field not 
included 


addr-spec derived 
from Generic Number 
(ACgPN) address 
signals if available 
or network provided 
value 


Header field not 
included 


Y(note1) 


N 


Derived from Calling 

Party Number 

parameter address 

signals 

(See table 14) 


if APRI = "allowed", 
Tel URL derived from 
Calling Party Number 
parameter address 
signals (See table 14) 
if APRI = 'restricted', 
SIP or SIPS URI with 
addr spec 

'anonymous@anony 
mous. invalid' (note 2) 


If Calling Party 
Number parameter 
APRI = 'restricted' 
then priv-value =: 'id'. 
For other APRI 
settings Privacy 
header is not 
included or if 
included, 'id' is not 
included 
(See table 16) 


Y 


Y 


Derived from Calling 

Party Number 

parameter address 

signals 

(See table 14) 


Derived from Generic 
Number (ACgPN) 
address signals 
(See table 13) 


If Calling Party 
Number parameter 
APRI = 'restricted' 
then priv-value =: 'id'. 
For other APRI 
settings Privacy 
header is not 
included or if 
included, 'id' is not 
included 
(See table 16) 




NOTE 1 : A Network Provided CLI in the CgPN parameter may occur on a call to IMS. Therefore in order to allow the 
'display' of this Network Provided CLI at a SIP UAS it shall be mapped into the SIP From header. It is also 
considered suitable to map into the P-Asserted-ldentity header since in this context it is a fully authenticated 
CLI related exclusively to the calling line, and therefore as valid as a User Provided Verified and Passed CLI 
for this purpose. 

NOTE 2: The 'From' header may contain an 'Anonymous URI'. An 'Anonymous URI' includes information that does not 
point to the calling party. RFC 3261 [1 9] recommends that the display-name component contains 
"Anonymous". The Anonymous URI itself should have the value "anonymous@anonymous. invalid". 

NOTE 3: This combination of CgPN and ACgPN is an error case and this is shown here to ensure consistent mapping 
across different implementations. 



£75/ 



3GPP TS 29.163 version 6.12.0 Release 6 



33 



ETSI TS 129 163 V6.12.0 (2009-06) 



Table 13: Mapping of generic number (additional calling party number) to SIP from header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Generic Number 
Number Qualifier 
Indicator 


'additional calling party 
number' 


From header field 


display-name (optional) and 
addr-spec 


Nature of Address 
Indicator 


'national (significant) 
number' 


Tel URL 


Add CO (of the country where 
the MGCF is located) to GN 
address signals to construct 
E.1 64 number in URI. Prefix 
number with '+'. 


'international number' 


Map complete GN address 
signals to E.1 64 number in 
URI. Prefix number with '+'. 


Address signal 


if NOA is 'national 

(significant) number' {hen 

the format of the address 

signals is: 

NDC+SN 

If NOA is 'international 

number' 

then the format of the 

address signals is: 

CO + NDC + SN 






Tel URL 


CC+NDC+SNasE.164 
number in URI. Prefix number 
with '+'. 



Table 14: lUlapping of calling party number parameter to SIP P-Asserted-ldentity header fields 



BICC/ISUP Parameter/ 
field 


Value 


SIP component 


Value 


Calling Party Number 




P-Asserted-ldentity header 
field 




Nature of Address 
Indicator 


'national (significant) 
number' 


Tel URL 


Add CC (of the country 
where the MGCF is 
located) to CgPN address 
signals to construct E.1 64 
number in URI. Prefix 
number with '+'. 


'international number" 


Map complete CgPN 
address signals to E.1 64 
number in URI. Prefix 
number with '+'. 


Address signal 


If NOA is 'national 

(significant) number' then 

the format of the address 

signals is: 

NDC + SN 

If NOA is 'international 

number' 

then the format of the 

address signals is: 

CC + NDC + SN 
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Table 15: Mapping of BlCC/iSUP Calling Party Number parameter to SIP From header fields 



BICC/ISUP parameter/ 
field 


Value 


SIP component 


Value 


Calling Party Number 




From header field 




Nature of Address 
Indicator 


'national (significant) 
number' 


Tel URL 


Add CC (of the country 
where the MGCF is 
located) to CgPN address 
signals then map to 
construct E.164 number in 
URI. Prefix number with 


'international number' 


IVIap complete CgPN 
address signals to 
construct E.164 number in 
URI. Prefix number with 


Address signal 


If NOA is 'national 

(significant) number' \\r\en 

the format of the address 

signals is: 

NDC + SN 

If NOA is 'international 

number' 

then the format of the 

address signals is: 

CC + NDC + SN 


Tel URL 


CC+NDC+SN as E.164 
number in URI. Prefix 
number with '+'. 



Table 16: IVIapping of BICC/ISUP APRIs into SIP privacy header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Calling Party Number 




Privacy header field 


priv-value 


APRI 

(See to determine which 

APRI to use for this 

mapping) 


'presentation restricted' 


Priv-value 


'Id' 

('id' included only if the P- 

Asserted-ldentity header is 

included in the SIP 

INVITE) 


'presentation allowed' 


Priv-value 


omit Privacy header 
or Privacy header without 
'id' if other privacy service 
is needed 


NOTE: When Calling Party Number parameter exists, P-Asserted-ldentity header is always derived from it as 
in table 14. 



7.2.3.2.2.4 



Max Forwards header 



If the Hop Counter procedure is supported in the CS network, the O-MGCF shall use the Hop Counter parameter to 
derive the Max-Forwards SIP header. Due to the different default values (that are based on network 
demands/provisions) of the SIP Max-Forwards header and the Hop Counter, an adaptation mechanism shall be used to 
adopt the Hop Counter to the Max Forwards at the O-MGCF. For example, the following guidelines could be applied. 

a) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP 
entity, regardless of intervening interworking, and similarly for Hop Counter. 

b) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the 
maximum number of hops that may be expected of a validly routed call. 

The table 17 shows the principle of the mapping: 
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Table 17: Hop counter-Max forwards 



Hop Counter 



Y 



Max-Forwards 



NOTE: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism. 



The Principle of adaptation could be implemented on a basis of the network provision, trust domain rules and bilateral 
agreement. 



7.2.3.2.3 



Receipt of CONTINUITY 



0-MGCF 



COT(success) 



SDP indicating 
pre-conditions 
met 



Figure 14: Receipt of COT (success). 

When the requested preconditions in the IMS (if any) have been met and if possible outstanding continuity procedures 
have successfully been completed (COT with the Continuity Indicators parameter set to 'continuity check successful' is 
received), a SDP offer (e.g. a SIP UPDATE request) shall be sent for each early SIP dialogue confirming that all the 
required preconditions have been met. 



7.2.3.2.4 



Sending of ACM and awaiting answer indication 



If the Address Complete Message (ACM) has not yet been sent, the following cases are possible trigger conditions that 
shall lead to the sending the address complete message (ACM). 

• the detection of end of address signalling by the expiry of Timer T i/W| or, 

0-MGCF 





lAM 


^ 






SAM 




~UT i/wi running 




SAM 


w 


~LTi/wi running 


w 

ACM (no indication) 


HXi/wi elapses 
J INVITE 


^ 


Ring tone 




^ 


► 


^ 









Figure 15: Sending of ACM T i/Wj elapses 

the reception of the first 180 Ringing or. 
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0-MGCF 



ACM (Subscriber Free) 



Ring tone 



180 Ringing 



Figure 16: Sending of ACIU! (Receipt of first 180 ringing) 

• Ti/w 2 expires after the initial INVITE is sent. 

0-MGCF 



lAM 


INVITE 


w 


^ 


^ ACM (no indication) 


Y Ti/w 2 


Ring tone 




•^ 





Figure 17: Sending of ACIU! (Ti/wj elapses) 

The sending of an awaiting answer indication is described in clause 9.2.3.3 

7.2.3.2.5 Coding of the ACM 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.5.1 Backward call indicators 

bits AB Charge indicator Contributors 

1 charge 
bits DC Called party's status indicator 

1 subscriber free if the 180 Ringing has been received. 

no indication otherwise 
bits FE Called party's category indicator 

no indication 
bits HG End-to-end method indicator 

00 no end-to-end method available 
bit I Interworking indicator 

1 interworking encountered 

bit J End-to-end information indicator 

no end-to-end information available 
bit K ISDN user part/BICC indicator 
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ISDN user part not used all the way 
bit L Holding indicator (national use) 

holding not requested 
bit M ISDN access indicator 

terminating access non-ISDN 
bit N Echo control device indicator 

1 Incoming echo control device included 

7.2.3.2.6 Sending of the Call Progress message (CPG) 

If the Address Complete Message (ACM) has already been sent, the O-MGCF shall send the Call Progress message 
(CPG) when receiving the following message: 

the first SIP 180 Ringing provisional response. 

O-MGCF 
CPG (Alerting) 



<- 



180 Ringing 

< 



Figure 18: Sending of CPG(Alerting) 

7.2.3.2.7 Coding of the CPG 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.7.1 Event information 

bits G-A Event indicator 

1 alerting 

7.2.3.2.7a Receipt of 200 OK(INVITE) 

Upon receipt of the first 200 OK (INVITE), the O-MGCF shall send an Answer Message (ANM) or Connect message 
(CON) as described in clauses 7.2.3.2.8 to 7.2.3.2.11. 

The O-MGCF shall not progress any further early dialogues to established dialogues. Therefore, upon the reception of a 
subsequent final 200 (OK) response for any further dialogue for an INVITE request (e.g., due to forking), the O-MGCF 
shall: 

1) acknowledge the response with an ACK request; and 

2) send a BYE request to this dialog in order to terminate it. 

7.2.3.2.8 Sending of the Answer Message (ANM) 

Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has already been sent, the O- 
MGCF shall send the Answer Message (ANM) to the preceding exchange. 

Note: Through connection and the stop of awaiting answer indication are described in clause 9.2.3.3 



£75/ 



3GPP TS 29.1 63 version 6.1 2.0 Release 6 38 ETSI TS 1 29 1 63 V6.1 2.0 (2009-06) 

0-MGCF 

200 OK (INVITE) 



ANM 
< 



<- 



Figure 19: Sending of ANIU! 

7.2.3.2.9 Coding of the ANM 

7.2.3.2.9.1 Backwards Call Indicators 

If Backwards Call Indicators are included in the ANM, then the coding of these parameters shall be as described in 
clause 7.2.3.2.5.1. 

7.2.3.2.10 Sending of the Connect message (CON) 

Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has not yet been sent, the O- 
MGCF shall send the Connect message (CON) to the preceding exchange. 

0-MGCF 

200 OK (INVITE) 



CON 



-4- 



Figure 20: Sending of CON 

7.2.3.2.11 Coding of the CON 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.2.3.2.1 1 .1 Backward call indicators 

The Called Party's status indicator (Bit DC) of BCI parameter is set to "no indication". The other BCI indicators shall be 
set as described in clause 7.2.3.2.5.1 

7.2.3.2.12 Receipt of Status Codes 4xx, 5xx or 6xx 

0-MGCF 



REL 



Status Code 
4xx, 5xx or 6xx 



Figure 21 : Receipt of Status codes 4xx, 5xx or 6xx 

When receiving SIP response with status codes 4xx, 5xx or 6xx, the O-MGCF shall send a REL message. The coding of 
the Cause parameter value in the REL message is derived from the SIP Status code received according to table 18. The 
Cause Parameter Values are defined in ITU-T Recommendation Q.850 [38]. 

In all cases where SIP itself specify additional SIP side behaviour related to the receipt of a particular INVITE response 
these procedures should be followed in preference to the immediate sending of a REL message to BICC/ISUP. 

If there are no SIP side procedures associated with this response, the REL shall be sent immediately. 
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NOTE: Depending upon the SIP side procedures applied at the O-MGCF it is possible that receipt of certain 

4xx/5xx/6xx responses to an INVITE may in some cases not result in any REL message being sent to the 
BICC/ISUP network. For example, if a 401 Unauthorized response is received and the O-MGCF 
successfully initiates a new INVITE containing the correct credentials, the call will proceed. 



Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF 



<-REL (cause code) 


<-4xx/5xx/6xx SIP Message 


127 (interworking unspecified) 


400 Bad Request 


127 (interworking unspecified) 


401 Unauthorized 


127 (interworking unspecified) 


402 Payment Required 


127 (interworking unspecified) 


403 Forbidden 


1 (Unallocated number) 


404 Not Found 


127 (Interworking unspecified) 


405 IVIethod Not Allowed 


127 (interworking unspecified) 


406 Not Acceptable 


127 (interworking unspecified) 


407 Proxy authentication required 


127 (interworking unspecified) 


408 Request Timeout 


22 (Number changed) 


410 Gone 


127 (interworking unspecified) 


413 Request Entity too long 


127 (interworking unspecified) 


414 Request-URI too long 


127 (interworking unspecified) 


415 Unsupported IVIedia type 


127 (interworking unspecified) 


416 Unsupported URI scheme 


127 (interworking unspecified) 


420 Bad Extension 


127 (interworking unspecified) 


421 Extension required 


127 (interworking unspecified) 


423 Interval Too Brief 


20 Subscriber absent 


480 Temporarily Unavailable 


127 (interworking unspecified) 


481 Call/Transaction does not exist 


127 (interworking unspecified) 


482 Loop detected 


127 (interworking unspecified) 


483 Too many hops 


28 (Invalid Number format) 


484 Address Incomplete 


127 (interworking unspecified) 


485 Ambiguous 


17 (User busy) 


486 Busy Here 


127 (Interworking unspecified) or 
not interworked. (Note 1) 


487 Request terminated 


127 (interworking unspecified) 


488 Not acceptable here 


127 (interworking unspecified) 


493 Undecipherable 


127 (interworking unspecified) 


500 Server Internal error 


127 (interworking unspecified) 


501 Not implemented 


127 (interworking unspecified) 


502 Bad Gateway 


127 (interworking unspecified) 


503 Service Unavailable 
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<-REL (cause code) 


<-4xx/5xx/6xx SIP Message 


127 (interworking unspecified) 


504 Server timeout 


127 (interworl<ing unspecified) 


505 Version not supported 


127 (interworl<ing unspecified) 


513 Message too large 


127 (interworl<ing unspecified) 


580 Precondition failure 


17 (User busy) 


600 Busy Everywhere 


21 (Call rejected) 


603 Decline 


1 (unallocated number) 


604 Does not exist anywhere 


127 (interworking unspecified) 


606 Not acceptable 


Note 1 - No interworking if the 0-MGCF previously issued a CANCEL request for 

the INVITE. 

Note 2 - The 4xx/5xx/6xx SIP Messages that are not covered in this table are not 

interworked. 



7.2.3 2.13 



Receipt of a BYE 



0-MGCF 



REL 
(Cause value 16) 



BYE 



Figure 22: Receipt of BYE method 

NOTE: If an optional Reason header field is included in the BYE, then the Cause Value can be mapped to the 
ISUP Cause Value field in the ISUP REL. The mapping of the Reason header to the Cause Indicators 
parameter is out of the scope of the present specification. 

On receipt of a BYE method, the O-MGCF sends a REL message with Cause Code value 16 (Normal Call Clearing). 



7.2.3.2.14 



Receipt of the Release Message 



In the case that the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been received the 
O-MGCF shall send a BYE method. If the final response (i.e. 200 OK (INVITE)) has not already been received the O- 
MGCF shall send a CANCEL method. 



7.2.3.2.15 



Receipt of RSC, GRS or CGB (H/W oriented) 



If a RSC, GRS or CGB (H/W oriented) message is received and a final response (i.e. 200 OK (INVITE) has already 
been received the O-MGCF shall send a BYE method. If a final response (i.e. 200 OK (INVITE)) has not already been 
received the O-MGCF shall send a CANCEL method. 

7.2.3.2.16 Autonomous Release at O-MGCF 

If the O-MGCF determines due to internal procedures that the call shall be released then the MGCF shall send 

- A BYE method if the ACK has been sent. 

- A CANCEL method before 200 OK (INVITE) has been received. 

NOTE: The MGCF shall send the ACK method before it sends the BYE, if 200 OK (INVITE) is received. 
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Table 18a: Autonomous Release at 0-MGCF 



REL^ 
Cause parameter 


Trigger event 


^SIP 


As determined by 
BICC/ISUP procedure. 


COT received with the 

Continuity Indicators 

parameter set to 

'continuity cliecl< failed 

(ISUPonly)orthe 

BICC/ISUP timer T8 

expires. 


CANCEL or BYE according to 

the rules described in this 

subclause. 


REL with cause value 
47 (resource 
unavailable, 
unspecified). 


Internal resource 

reservation 

unsuccessful 


As determined by SIP 
procedure 


As determined by 
BICC/ISUP procedure. 


BICC/ISUP procedures 

result in generation of 

autonomous REL on 

BICC/ISUP side. 


CANCEL or BYE according to 

the rules described in this 

subclause. 


Depending on tlie SIP 
release reason. 


SIP procedures result 

in a decision to release 

the call. 


As determined by SIP 
procedure. 



7.2.3.2.17 Special handling of 580 precondition failure received in response to either an 

INVITE or UPDATE 

A 580 Precondition failure response may be received as a response either to an INVITE or to an UPDATE request. 

7.2.3.2.1 7.1 580 Precondition failure response to an INVITE 

Release with cause code as indicated in table 17 is sent immediately to the BICC/ISUP network. 

7.2.3.2.1 7.2 580 Precondition failure response to an UPDATE within an early dialog 

Release with Cause Code '127 Interworking' is sent immediately to the BICC/ISUP network. A BYE request is sent for 
the INVITE transaction within which the UPDATE was sent. 



7.2.3.2.18 



Sending of CANCEL 



0-MGCF 



COT (failure) 



CANCEL 



Figure 23: Receipt of COT (failure). 

CANCEL shall be sent if the Continuity message is received with the Continuity Indicators parameter set to 'continuity 
checic failed' or the ISUP (or BICC) timer T8 expires. 
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7.2.3.2.19 



Receipt of SIP redirect (3xx) response 



0-MGCF 



REL 

(Cause value 127) 



SIP response 
code 3xx 



Figure 24: Receipt of SIP response code 3xx 

When receiving a SIP response with a response code 3xx, the defauh behaviour of the O-MGCF is to release the call 
with a cause code value 127 (Interworking unspecified). 

NOTE: The O-MGCF may also decide for example to redirect the call towards the URIs in the Contact header 
field of the response as an operator option, but such handling is outside of the scope of the present 
document. 



7.2.3.3 



Timers 



Table 19: Timers for interworking 



Symbol 


Time-out value 


Cause for initiation 


Normal termination 


At expiry 


Reference 


Ti/w1 


4 s to 6 s (default 


When last address 


At the receipt of 


Send INVITE, send the 


7.2.3.2.1 




of 4 s) 


message is received 


fresh address 


address complete 


7.2.3.2.4 






and the minimum 


information. 


message and insert ring 


(Notel) 






number of digits 




tone 








required for routing 












the call have been 












received. 








Ti/w2 


4 s to 1 4 s 


When INVITE is sent. 


On reception of 180 


Send ACM (no 


7.2.3.2.4 




(default of 4 s) 




Ringing ,or200OK 
INVITE. 


indication) and send the 
awaiting answer 
indication (e.g. ring tone) 
or appropriate progress 
announcement to the 
calling party. 


7.2.3.2.1 


NOTE 1 : This timer is used when overlap signalling is 


received from BICC/IS 


UP network. 





7.3 Interworking between CS networks supporting BICC and 
the IIVI CN subsystem 

The control plane between CS networks supporting BICC and the IM CN subsystem supporting SIP, where the 
underlying network is SS7 and IP respectively is as shown in figures 25, 26 and 27. 
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BICC 



STC 



MTP3 
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RTCC 
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MTP3 M3UA 
MTP2 SCTP 
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SS7 signalling 
function 



Signalling gateway 
function 
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M3UA 

SCTP 
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TCP/ 
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Media gateway 
control function 
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SIP signalling 
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Figure 25: Control Plane interworking between CS networks supporting BICC over IVITPS and the IIVI 

CN subsystem 
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SS7 signalling 
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Signalling gateway 
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Media gateway 
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SIP signalling 
function 



Figure 26: Control Plane interworking between CS networks supporting BICC over MTP3B over AAL5 

and the IM CN subsystem 
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Figure 27: Control Plane interworking between CS networks supporting BICC 
over STC and M3UA and the IIVI CN subsystem 
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7.3.1 Services performed by network entities in tine control plane 

Services offered by the network entities in the control plane are as detailed in clause 7.2.1. 

If ATM transport is applied between the SS7 Signalling function and the Signalling Gateway Function, they shall apply 
MTP3B (ITU-T Recommendation Q.2210 [46]) over SSCF (ITU-T Recommendation Q.2140 [45]) over SSCOP (ITU- 
T Recommendation Q.21 10 [44]) over AAL5 (ITU-T Recommendation 1.363.6 [43]) as depicted in figure 26. 

If IP transport is applied between the SS7 Signalling function and the MGCP, they shall support and apply M3UA, 
SCTP and IP (either IPv4, see RFC 791 [16], or IPv6, see RFC 2460 [39]), as depicted in figure 27. 

7.3.2 Signalling interactions between network entities in the control plane 

7.3.2.1 Signalling between the SS7 signalling function and MGCF 

See clause 7.2.2.1. 

7.3.2.1 .1 Signalling from MGCF to SS7 signalling function 

See clause 7.2.2.1.1. 

7.3.2.1 .2 Signalling from SS7 signalling function to MGCF 

See clause 7.2.2.1.2. 

7.3.2.1 .3 Services offered by STC, SCTP and M3UA 

See clause 7.2.2.1.3. 

7.3.2.1.3.1 Services offer by SCTP 

See clause 7.2.2.1.3.1. 

7.3.2.1 .3.2 Services offered by M3UA 

See clause 7.2.2.1.3.2. 

7.3.2.1.3.3 Services offered by STC 

STC provides the services for the transparent transfer of STC user information, e.g. BICC, between STC users, i.e. the 
SS7 signalling function and the MGCF (see 3GPP TS 29.205 [14]). 

STC performs the functions of data transfer service availability reporting and congestion reporting to the STC user and 
User part availability control. See ITU-T Recommendation Q.21 50.1 [29]. 

7.3.2.2 Signalling between the MGCF and SIP signalling function 

See clause 7.2.2.2. 

7.3.3 SIP-BICC protocol interworking 

7.3.3.1 Incoming call interworking from SIP to ISUP at l-MGGF 

7.3.3.1.1 Sending of lAM 

On reception of a SIP INVITE requesting an audio session, the I-MGCF shall send an lAM message. 
The I-MGCF shall interwork forked INVITE requests with different request URIs. 
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I-MGCF 



INVITE 



lAM 



Figure 28: receipt of Invite 

The I-MGCF shall reject an INVITE request for a non-audio session by sending a status code 488 "Not Acceptable 
Here". If audio media streams and non-audio media streams are contained in a single INVITE request, the non-audio 
media streams shall be rejected in the SDP answer, as detailed in RFC 3264 [36]. 

The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early 
dialog as described in RFC 3261 [19]. 



7.3.3.1.2 Coding of lAM 

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4]. 

7.3.3.1 .2.1 Called party number 
See clause 7.2.3.1.2.1. 

7.3.3.1 .2.2 Nature of connection indicators 
bits BA Satellite indicator 

1 one satellite circuit in the connection 

bits DC Continuity indicator (BICC) 

no COT to be expected, if the received SDP does not contain precondition information or 

indicates that all preconditions are fulfilled, and all local resource reservation is completed. 

1 COT to be expected, if the received SDP indicates that precondition is not fulfilled or any local 

resource reservation is not completed. 

bit E Echo control device indicator 

1 outgoing echo control device included 

7.3.3.1 .2.3 Forward call indicators 
See clause 7.2.3.1.2.3. 

7.3.3.1 .2.4 Calling party's category 
See clause 7.2.3.1.2.4. 

7.3.3.1.2.5 Transmission medium requirement 
See clause 7.2.3.1.2.5. 
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7.3.3.1 .2.6 Calling party number 
See clause 7.2.3.1.2.6. 

7.3.3.1.2.7 Generic number 
See clause 7.2.3.1.2.7. 

7.3.3.1.2.8 User service information 
See clause 7.2.3.1.2.8. 

7.3.3.1 .2.9 Hop counter (National option) 
See clause 7.2.3.1.2.9. 
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Figure 29: Sending of COT 

When the requested preconditions in the IMS have been met, the lAM has already been sent, then the Continuity 
message shall be sent indicating "continuity check successful". 

7.3.3.1 .4 Sending of 1 80 Ringing 

See clause 7.2.3.1.4 

7.3.3.1 .5 Sending of the 200 OK (INVITE) 

See clause 7.2.3.1.5. 

7.3.3.1 .6 Sending of the Release message (REL) 
See clause 7.2.3.1.6. 

7.3.3.1.7 Coding of the REL 

See clause 7.2.3.1.7. 

7.3.3.1 .8 Receipt of the Release Message 

See clause 7.2.3.1.8. 

7.3.3.1 .9 Receipt of RSC, GRS or COB (H/W oriented) 
See clause 7.2.3.1.9. 
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7.3.3.1.10 Internal through connection of the bearer path 

The through connection procedure is described in subclauses 9.2.3.1.7 and 9.2.3.2.7. 

7.3.3.1.11 Out of Band DTMF 

If a SIP UA sends DTMF tones to the IM-MGW , the IM-MGW may send this information via the Mn interface to the 
MGCF. The MGCP shall send to the BICC network the APM message with the following values for the different 
parameters: 

Action indicator in accordance with the requested DTMF transport function 

Signal in accordance with which DTMF digit to send 

Duration in accordance with the required duration of the DTMF digit. 

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF 
may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF 
signal and duration information on the user plane of the IM CN subsystem according to RFC 2833 [34]. 

The interactions with the IM-MGW are shown in clause 9.2.8. 

7.3.3.2 Outgoing Call Interworking from BICC to SIP at 0-MGCF 

7.3.3.2.1 Sending of INVITE 

The following particularities applies for a BICC lAM received case, with regard to the already specified in clause 

7.2.3.2.1. 

An INVITE with precondition not yet satisfied on receipt of BICC lAM is sent. 

7.3.3.2.2 Coding of the INVITE 

7.3.3.2.2.1 REQUEST URI Header 
See clause 7.2.3.2.2.1 

7.3.3.2.2.2 SDP Media Description 

The O-MGCF shall indicate that precondition is not met. 

The SDP media description will contain precondition information as per RFC 3312 [37]. 

The O-MGCF shall include the AMR codec transported according to RFC 3267 [23] with the options listed in clause 
5.1.1 of 3GPP TS 26.236 [32] in the SDP offer. Within the SDP offer, the O-MGCF should also provide SDP RR and 
RS bandwidth modifiers specified in IETF RFC 3556 [59] to disable RTCP, as detailed in Clause 7.4 of 3GPP TS 
26.236 [32]. 

7.3.3.2.2.3 P-Asserted-ldentity and privacy Ineader fields 
See clause 7.2.3.2.2.3 

7.3.3.2.2.4 Max Forwards Ineader 
See clause 7.2.3.2.2.4 
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7.3.3.2.3 Sending of UPDATE 

0-MGCF 
COT (success) 



-> 



UPDATE 

► 



Figure 30: Receipt of COT (success). 



The UPDATE shall be sent for each early SIP dialogue confirming that all the required preconditions have been met 
when all the following conditions are met. 

1. A Continuity message, with the Continuity Indicators parameter set to "continuity" shall be received. 

2. The requested preconditions in the IMS (if any) are met. 

In addition, depending on which bearer set-up procedure used for the call one of the following condition shall be 

met 

The event Bearer Set-up indication - for the forward bearer set-up case where the incoming Connect Type is 
"notification not required", which indicate successful completion of bearer set-up, shall also be received by the 
Incoming bearer set-up procedure, (ITU-T Recommendation Q. 1902.4 [30] clause 7.5) 

Bearer Set-up Connect indication for the backward call set-up case, which indicate successful completion of 
bearer set-up, shall also be received by the Incoming bearer set-up procedure, (ITU-T Recommendation 
Q.1902.4 [30] clause 7.5) 

BNC set-up success indication for cases using bearer control tunnelling which indicate successful completion of 
bearer set-up, shall also be received by the Incoming bearer set-up procedure, (ITU-T Recommendation 
Q.1902.4 [30] clause 7.5) 



7.3.3.2.4 Sending of ACM and Awaiting Answer indication 

See clause 7.2.3.2.4 

The sending of an awaiting answer indication is described in clause 9.2.3.1. and clause 9.2.3.2. 

7.3.3.2.5 Coding of the ACM 

7.3.3.2.5.1 Backward call indicators 

See clause 7.2.3.2.5.1 

7.3.3.2.6 Sending of the Call Progress message (CPG) 

See clause 7.2.3.2.6. 

7.3.3.2.7 Coding of the CPG 

7.3.3.2.7.1 Event information 

See clause 7.2.3.2.7.1. 

7.3.3.2.7a Receipt of 200 OK (INVITE) 

See clause 7.2.3.2.7a. 
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7.3.3.2.8 Sending of the Answer Message (ANM) 

See clause 7.2.3.2.8. 

7.3.3.2.9 Coding of the ANM 

See clause 7.2.3.2.9. 

7.3.3.2.10 Sending of the Connect message (CON) 
See clause 7.2.3.2.10. 

7.3.3.2.11 Coding of the CON 

See clause 7.2.3.2.11. 

7.3.3.2.1 1 .1 Backward call indicators 

See clause 7.2.3.2.11.1. 

7.3.3.2.12 Receipt of Status Codes 4xx, 5xx or 6xx 

See clause 7.2.3.2.12. 

7.3 3.2.13 Receipt of a BYE 

See clause 7.2.3.2.13. 

7.3.3.2.14 Receipt of the Release Message 

See clause 7.2.3.2.14. 

7.3.3.2.15 Receipt of RSC, GRS or CGB (H/W oriented) 
See clause 7.2.3.2.15. 

7.3.3.2.16 Out of Band DTMF 

If a SIP UA sends DTMF tones to the IM-MGW, the IM-MGW may send this information via the Mn interface to the 
MGCF. The MGCP shall send to the BICC network the APM message with the following values for the different 
parameters: 

Action indicator in accordance with the requested DTMF transport function 

Signal in accordance with which DTMF digit to send 

Duration in accordance with the required duration of the DTMF digit. 

If the BICC network sends an APM message with DTMF signal, duration and action indicator to the MGCF, the MGCF 
may send this information to the IM-MGW via the Mn interface. The IM-MGW shall send the corresponding DTMF 
signal and duration information on the user plane of the IM CN subsystem according to RFC 2833 [34]. 

The interaction with the IM-MGW is shown in clause 9.2.8. 

7.3.3.2.17 Sending of CANCEL 

See clause 7.2.3.2.18. 

7.3.3.2.18 Autonomous Release at 0-MGCF 

See clause 7.2.3.2.16. 
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7.3.3.2.19 Special handling of 580 precondition failure received in response to either an 

INVITE or UPDATE 

See clause 7.2.3.2.17. 



7.3.3.2.20 Receipt of SIP redirect (3xx) response 

See clause 7.2.3.2.19. 

7.3.3.3 Timers 

See clause 7.2.3.3. 



7.4 Supplementary services 



The following sub-clauses describe the MGCF behaviour related to supplementary services as defined in ITU-T 
RecommendationsQ.730 to ITU-T Q.737. [42]. 

7.4.1 Calling line identification presentation/restriction (CLIP/CLIR) 

The inter working between the Calling Party Number parameter and the P-Asserted-ID header and vice versa used for 
the CLIP-CLIR service is defined in the clauses 7.2.3.1.2.6 and 7.2.3.2.2.6. This inter working is essentially the same as 
for basic call and differs only in that if the CLIR service is invoked the "Address Presentation Restriction Indicator 
(APRI)" (in the case of ISUP to SIP calls) or the "priv value" of the "calUng" Privacy header field (in the case of SIP to 
ISUP calls) is set to the appropriate "restriction/privacy" value. 

In the specific case of ISUP originated calls, use of the CLIP service additionally requires the ability to determine 
whether the number was network provided or provided by the access signalling system. Due to the possible SIP 
indication of the P-Asserted-Identity the Screening indicator is set to network provided as default. For the CLIP-CLIR 
service the mapping of the APRI from privacy header at the O-MGCF is described within table 16 in Clause 7.2.3.2.2.6. 

At the O-MGCF the presentation restricted indication shall be mapped to the privacy header = "id" and "header". This is 
described in table 5 in clause 7.2.3.1.2.6. 

7.4.2 Connected line presentation and restriction (COLP/COLR) 

The COLP/COLR services are only to be interworked between trusted nodes - that is before passing any COLP/COLR 
information over the SIP-BICC/ISUP boundary the MGCF shall satisfy itself that the nodes on the BICC/ISUP side to 
which the information is to be passed are trusted. 

7.4.2.1 Incoming Call Interworking From SIP to BICC/ISUP At The l-MGCF 

7.4.2.1 .1 INVITE to lAM interworking (SIP to ISUP/BICC calls) 

In the case of SIP to ISUP/BICC calls the I-MGCF may invoke the COLP service as an operator option by setting the 
"Connected Line Identity Request indicator" parameter of the "Optional forward call indicator" of the lAM to 
"requested". 

NOTE: This implies that all outgoing calls will invoke the COLP/COLR service. 

7.4.2.1.2 ANM/CON to 200 OK (INVITE) 

Tables 20 and 21 specify the interworking required in the case when the COLP has been automatically requested on 
behalf of the originating SIP node. The table also indicates the inter workings required if the COLP service has been 
invoked and the called party has or has not invoked the COLR service. 
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Table 20 - Mapping to P-Asserted-ldentity and Privacy Header Fields 



SIP Component 


Setting 


P-Asserted-ldentity 


See table 21 


Privacy 


See table 22 



Table 21 - IVIapping of connected number parameter to SIP P-Asserted-ldentity header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Connected Number 




P-Asserted-ldentity header 
field 




Nature of Address 
Indicator 


"national (significant) 
number" 


Tel URL 


Add CC (of the country 
where the IVIGCF is 
located) to Connected PN 
address signals to 
construct E.164 number in 
URI. Prefix number with 
'-I-'. 


"international number" 


Map complete Connected 
address signals to 
construct E.164 number in 
URI. Prefix number with 


Address signal 


If NOA is "national 

(significant) number" then 

the format of the address 

signals is: 

NDC + SN 

If NOA is "international 

number" 

then the format of the 

address signals is: 

CC + NDC + SN 






Tel URL 


CC-i-NDC-i-SN as E.164 
number in URI. Prefix 
number with "+". 



Table 22: IVIapping of BICC/ISUP APRIs into SIP privacy header fields 



BICC/ISUP parameter / 
field 


Value 


SIP component 


Value 


Connected Number 




Privacy header field 


priv-value 


APR! 

(See to determine which 

APRI to use for this 

mapping) 


"presentation restricted" 


Priv-value 


"id" 

("id" included only if the P- 

Asserted-ldentity header is 

included in the SIP 

INVITE) 


"presentation allowed" 


Priv-value 


omit Privacy header 
or Privacy header without 
"id" if other privacy service 
is needed 
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7.4.2.2 Outgoing Call Interworking from BICC/ISUP to SIP at 0-MGCF 

7.4.2.2.1 lAM to INVITE interworking (ISUP to SIP calls) 

The O-MGCF determines that the COLP service has been requested by the calling party by parsing the "Optional 
Forward Call Indicators" field of the incoming lAM. If the "Connected Line Identity Request indicator" is set to 
"requested" then the BICC/ISUP to SIP interworking node shall ensure that any backwards "connected party" 
information is interworked to the appropriate parameters of the ISUP ANM or CON message sent backwards to the 
calling party as detailed within this clause. 

The O-MGCF has to store the status of the "Connected Line Identity Request indicator". 

7.4.2.2.2 1 XX to ANM or CON interworking 

If the P-Asserted-Identity header field is included within a IXX SIP response, the identity shall be stored within the O- 
MGCF together with information about the SIP dialogue of the IXX SIP response and be included within the ANM or 
CON message. In accordance with ISUP procedures a connected number shall not be included within the ACM 
message. The mapping of the of the P-Asserted-Identity and Privacy header fields is shown in tables 23 and 24. 

7.4.2.2.3 200 OK (INVITE) to ANM/CON interworking 

Tables 23 and 24 specify the interworking required in the case when the calling party has invoked the COLP service. 
The tables also indicate the interworking procedures required if the calling party has invoked the COLP service and the 
called party has or has not invoked the COLR service. 

If no P-Asserted-Identity header field is provided within the 200 OK (INVITE) message, the stored information 
previously received in last provisional IXX response of the same SIP dialogue shall be used. 

NOTE: Due to forking, other P-Asserted-Identities may have been received in different SIP dialogues. 

If the Calling Party has requested the COLP service (as indicated by the stored request status) but the 200 OK (INVITE) 
and previous IXX provisional responses do not include a P-Asserted-Identity header field, the O-MGCF shall set up a 
network provided Connected Number with an Address not Available indication. 

If the P-Asserted-Identity is available then the Connected number has to be setup with the screening indication network 
provided. The mapping of the P-Asserted-Identity and Privacy (if available) is shown in table 24. 
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Table 23 - Connected number parameter mapping 



<- ANM/CON 


«- 200 OK INVITE 


Connected Number (Network Provided) 


P-Asserted-ID 


Address Presentation Restriction Indication 


Privacy Value Field 



Table 24: Mapping of P-Asserted-ldentity and privacy headers to the iSUP/BICC connected number 

parameter 



SIP component 


Value 


BICC/ISUP parameter / field 


Value 


P-Asserted-ldentity 
header field (note 1) 


E.164 number 


Connected Number 






Number incomplete indicator 


"Complete" 


Numbering Plan Indicator 


"ISDN/Telephony (E.164)" 


Nature of Address Indicator 


If CC encoded in the URI 
is equal to the CC of the 
country where MGCF is 
located AND the next 
BICC/ISUP node is located 
in the same country then 
set to "national (significant) 
number" 

else set to "international 
number" 


Address Presentation Restricted 
Indicator (APR!) 


Depends on priv-value in 
Privacy header. 


Screening indicator 


Network Provided 


Addr-spec 


"CC 'NDC 'SN" from the 
URI 


Address signal 


if NOA is 'national 

(significant) number' then 

set to 

'NDC + 'SN' 

If NOA is 'international 

number' 

Then set to 'CC'-i-' 

NDC-i-'SN' 


Privacy header field is 
not present 




APRI 


Presentation allowed 


Privacy header field 


priv-value 


APRI 


"Address Presentation 
Restricted Indicator" 


priv-value 


"header' 


APRI 


Presentation restricted 


"user" 


APRI 


Presentation restricted 


"none" 


APRI 


Presentation allowed 


"id" 


APRI 


Presentation restricted 


NOTE 1 : It is possible that a P-Asserted -Identity header field includes both a TEL URI and a SIP or SIPS URI. 
In this case, the TEL URL is used. 



7.4.3 Direct Dialling In (DDI) 

A direct dialling in call is a basic call and no additional treatment is required by the MGCF. 

7.4.4 Malicious call identification 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.731.7 [42] under the 
clause "Interactions with other networks". 
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7.4.5 Sub-addressing (SUB) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.731.8 [42] under the 
clause "Interactions with other networks". 

7.4.6 Call Forwarding Busy (CFB)/ Call Forwarding No Reply (CFNR) / 
Call Forwarding Unconditional (CFU) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.732.2-4 [42] under the 
clause "Interactions with networks not providing any call diversion information". 



7.4.7 Call Deflection (CD) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.732.5 [42] under the 
clause "Interactions with other networks". 



7.4.8 Explicit Call Transfer (ECT) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.732.7 [42] under the 
clause "Interactions with other networks". 



7.4.9 Call Waiting 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Q.733.1 [42] under the clause "Interactions 
with other networks". 

7.4.10 Call Hold 

The service is interworked as indicated in 3GPP TS 23.228 [12]. 

7.4.10.1 Session hold initiated from the IM CN subsystem side 

The IMS network makes a hold request by sending an UPDATE or re-INVITE message with an "inactive" or a 
"sendonly" SDP attribute (refer to RFC 3264 [36]) , depending on the current state of the session. Upon receipt of the 
hold request from the IMS side, the MGCF shall send a CPG message to the CS side with a "remote hold" Generic 
notification indicator. To resume the session, the IMS side sends an UPDATE or re-INVITE message with a 'recvonly' 
or 'sendrecv' SDP attribute, depending on the current state of the session. Upon receipt of the resume request from the 
IMS side, the MGCF shall send a CPG message to the CS side with a "remove retrieval" Generic notification indicator. 
The user plane interworking of the hold/resume request is described in the clause 9.2.9. 
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2. BICC/ISUP: CPG (Hold) 


MGCF 










1 . SIP: UPDATE [SDP, a=sendonly/ 
inactive] 














3. S!P: 200 OK [SDP] 











5. BICC/ISUP: CPG (Retrieve) 




4. SIP: UPDATE [SDP, a=sendrecv/ 
recvonly] 












6. SIP: 200 OK TSDPl 









Figure 30a Session hold/resume initiated from the IIUI CN subsystem side 



7.4.10.2 



Session hold initiated from the CS network side 



When an MGCF receives a CPG message with a "remote hold" Generic notification indicator, the IVIGCF shall forward 
the hold request by sending an UPDATE or re-INVITE message containing SDP with \sendoniy or 'inactive' media. 

When an MGCF receives a CPG message with a "remote retrieval" Generic notification indicator, the MGCF shall 
forward the resume request by sending an UPDATE or re-INVITE message containing SDP with 'sendrecV or 
'recvonly' media. 

If the MGCF receives a CPG with "remote hold" or "remote retrieval" before answer, it shall forward the request using 
an UPDATE message. If the MGCF receives a CPG with "remote hold" or "remote retrieval" after answer, it should 
forward the request using re-INVITE but may use UPDATE. 

If link aliveness information is required at the IM-MGW while the media are on hold, the O-MGCF should provide 
modified SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] within the UPDATE or re-INVITE 
messages holding and retrieving the media to temporarily enable RTCP while the media are on hold, as detailed in 
Clause 7.4 of 3GPP TS 26.236 [32]. If no Unk ahveness information is required at the IM-MGW, the O-MGCF should 
provide the SDP RR and RS bandwidth modifiers previously used. 

The interworking does not impact the user plane, unless the MGCF provides modified SDP RR and RS bandwidth 
modifiers within the UPDATE or re-INVITE messages. If the MGCF provides modified SDP RR and RS bandwidth 
modifiers to the IMS side, the MGCF shall also provide modified SDP RR and RS bandwidths to the IM-MGW, as 
described in the clause 9.2.10. 
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MGCF 
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2. SIP: UPDATE [SDR, a=sendonly/ 
inactive] 






3. S!P: 200 OK [SDP] 













4. BICC/ISUP: CPG (Retrieve) 




5. SIP: UPDATE [SDP, a=sendrecv/ 
recvonly] 












6. SIP: 200 OK [SDPl 











Figure 30b Session hold/resume initiated from the CS networit side 



7.4.1 1 Call Completion on busy subscriber 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.3 [42] under the 
clause "Interactions with other networks". 

7.4.1 2 Completion of Calls on No Reply (CCNR) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.5 [42] under the 
clause "Interactions with other networks". 



7.4.13 Terminal Portability (TP) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.733.4 [42] under the 
clause "Interactions with other networks". 



7.4.14 Conference calling (CONF) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.734.1[42] under the 
clause "Interactions with other networks". 



7.4.15 Three-Party Service (3PTY) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.734.2 [42] under the 
clause "Interactions with other networks". 
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7.4.1 6 Closed User Group (CUG) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.1[42] under the 
Clause 1.5.2.4.2 "Exceptional procedures". 

7.4.17 Multi-Level Precedence and Pre-emption (MLPP) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.3 [42] under the 
clause "Interactions with other networks". 

7.4.18 Global Virtual Network Service (GVNS) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.735.6 [42] under the 
clause "Interactions with other networks". 

7.4.19 International telecommunication charge card (ITCC) 

An International Telecommunication charge card call is a basic call and no additional treatment is required by the 
MGCF. 



7.4.20 Reverse charging (REV) 



The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.736.3 [42] under the 
clause "Interactions with other networks". 

7.4.21 User-to-User Signalling (UUS) 

The actions of the MGCF at the ISUP/BICC side are described in ITU-T Recommendation Q.737.1[42] under the 
clause "Interactions with other networks". 

7.4.22 Multiple Subscriber Number (MSN) 

A MSN call is a basic call and no additional treatment is required by the MGCF. 



8 User plane interworking 

8.1 Interworking between IM CN subsystem and bearer 
independent CS network 

When the IM CN subsystem interworks with the bearer independent CS networks (e.g. CS domain of a PLMN, 3GPP 
TS 29.414 [25], 3GPP TS 29.415 [26], 3GPP TS 23.205 [27]), the Transport Network Layer (TNL) of the bearer 
independent CS network can be based e.g. on IP/UDP/RTP, or IP/UDP/RTP/IuFP, or ATM/AAL2/ framing protocol 
(e.g. lu framing) transport techniques. Figure 31 shows the user plane protocol stacks for the IM CS subsystem and 
bearer independent CS network interworking. If the same AMR configuration is used on the CS network side as on the 
IMS side, transcoding is not required. However, there is still a need to interwork between RTP/UDP/IP/L2/LI to 
TNL/LI. 
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Figure 31/1 : IM CN subsystem to bearer independent CS network user plane protocol stack 

8.1 .1 Transcoder-less Mb to Nb Interworking 
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Figure 31/2: IM CN subsystem to bearer independent CS network user plane protocol stack (optional 

in the event the codecs on both sides are the same) 

If no transcoder is inserted, the IM-MGW shall interwork the following procedures between the Nb and Mb interfaces. 

8.1.1.1 Initialisation 

. There is no need to interwork initialisation procedures between Nb and Mb interfaces see 3GPP TS 29.415 [26]. 



8.1.1.2 



Time alignment 



The purpose of the time alignment procedure on the Nb interface is to minimise the buffer delay in the RNC for 
downlink transmissions by adjusting the vocoder time reference within the network. No such procedure exists on the 
Mb interface, so the IM-MGW shall return NACK indication time alignment not supported according to 3GPP TS 

25.415 [26]. 
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8.1.1.3 



Rate control 



The rate control procedure signals to the peer entity the maximum rate among the currently allowed rates at which it can 
receive codec frames. Rate control only applies to AMR family codec configurations with multiple active modes. On 
the Nb interface, luFP provides for rate control via the exchange of RATE CONTROL and RATE CONTROL ACK 
PDUs. On the Mb interface, RFC 3267 [23] provides for in-band rate control via the Codec Mode Request (CMR) field 
of every codec frame. 

Interworking of rate control procedures at an IM-MGW between an Mb interface and a corresponding Nb interface only 
applies when the IM-MGW bridges compatible codec configurations between the interfaces without applying a 
transcoding function. An IM-MGW receiving a CMR from an Mb interface shall initiate the luFP rate control procedure 
on the corresponding Nb interface. An IM-MGW receiving a rate control request on an Nb interface shall adjust the 
CMR field of outgoing speech frames on the corresponding Mb interface. 



8.1.1.4 



Frame quality indication 



The Nb interface signals frame quality with the Frame Quality Classification (FQC) field of each speech frame PDU. 
See 3GPP TS 26.102 [50] and 3GPP TS 25.415 [26] for details. The FQC may have possible values: O=frame_good; 
l=frame_bad; 2=frame_bad_due_to_radio; and 3=spare. The Mb interface signals frame quality with the Q bit (frame 
quality indicator) field of each speech frame, as defined in RFC 3267 [23]. The Q bit may have values: l=speech_good; 
and 0=speech_bad or sid_bad. 

Tables 24a and 24b provide the mapping between Mb and Nb interfaces. 

Table 24a: Mapping of Mb (Q bit) onto Nb (FQC) 



Mb - Qbit 


Mb -FT 


Nb - FQC 


1 


X 








X 


1 



Table 24b: Mapping Nb onto Mb 



Nb - FQC 


Mb - Qbit 


Mb -FT 





1 


NO 


1 





NO DATA 


2 





NO 



8.1.1.5 



Framing 



Even when the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the IM-MGW 
shall perform translation between the frame formats defined for the two interfaces, since all codec configurations have 
different framing procedures for the two interfaces. The framing details for Nb are defined in 3GPP TS 26.102 [50] and 
3GPP TS 25.415 [26], although they do not describe the framing for ITU-T codecs other than G.71 1. The framing 
details for Mb are defined in RFC 3267 [23], RFC 3550 [51], RFC 3551 [52] and RFC 3555 [53]. 



8.1.1.6 



Transcoding 



Transcoding at the IM-MGW is avoided when the IM-MGW bridges compatible codec configurations between the Nb 
and Mb interfaces. Otherwise transcoding is necessary, which eliminates the need to interwork other user plane 
procedures between the interfaces. 



8.1.1.7 



Discontinuous transmission 



When the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the DTX procedures 
are normally interworked transparently by translating between the framing formats on the interfaces. All the ITU-T and 
AMR family codecs have configurations that are compatible between the Mb and Nb interfaces. 
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8.1.1.8 



Timing and sequence information 



The IM-MGW shall always correct out-of-sequence delivery between Nb and Mb interfaces, either by re-ordering 
frames, or by dropping frames that are out of sequence. 

When the luFP frame numbers are based on time and if the IM-MGW bridges compatible codec configurations between 
the Nb and Mb interfaces, it shall either correct jitter before forwarding PDUs or interwork the RTP timestamp (see 
RFC 3550 [51]) with the luFP Frame Number (see 3GPP TS 25.415 [26]) so that both the RTP timestamp and luFP 
frame number similarly reflect the nominal sampling instant of the user data in the packet. 

NOTE: Correcting jitter may cause additional delay. 

The RTP sequence number (see RFC 3550 [51]) is handled independently on Mb, i.e. it is not interworked with the 
luFP Frame Number (see 3GPP TS 25.415 [26]). 

8.2 Interworking between IM CN subsystem and TDM-based 
CS network 



It shall be possible for the IM CN subsystem to interwork with the TDM based CS networks (e.g. PSTN, ISDN or CS 
domain of a PLMN). Figure 32 describes the user plane protocol stack to provide the particular interworking. 
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Figure 32: IM CN subsystem to TDM-based CS network user plane protocol stack 



8.3 Transcoding requirements 



The IM CN subsystem supports the AMR codec as the native codec for basic voice services. For IM CN subsystem 
terminations, the IM MGW shall support the transport of AMR over RTP according to RFC 3267 [23]. The MGCF shall 
support the options of RFC 3267 Hsted within clause 5.1.1 of 3GPP TS 26.236 [32]. 

It shall be possible for the IM CN subsystem to interwork with the CS networks (e.g. PSTN, ISDN or a CS domain of a 
PLMN) by supporting AMR to G.711 transcoding (see ITU-T Recommendation G.71 1 [1]) in the IM-MGW. The IM- 
MGW may also perform transcoding between AMR and other codec types supported by CS networks. 

8.4 Diffserv code point requirements 

The IM-MGW shall perform DiffServ Code Point (DSCP) markings (see RFC 2474 [21]) on the IP packets sent 
towards the IM CN subsystem entity like UE or MRFP across the Mb interface to allow DiffServ compliant routers and 
GGSNs to schedule the traffic accordingly. 
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The IETF Differentiated Services architecture ( see RFC 2475 [22]) shall be used to provide QoS for the external bearer 

service. 

The DSCP shall be operator configurable. 



MGCF - IM-MGW Interaction 



9.1 



Overview 



The MGCF shall control the functions of the IM-MGW, which are used to provide the connection between media 
streams of an IP based transport network and bearer channels from a CS network. 

The MGCF shall interact with the IM-MGW across the Mn reference point. The MGCF shall terminate the signalling 
across the Mn interface towai'ds the IM-MGW and the IM-MGW shall terminate the signalling from the MGCF. 

The signalling interface across the Mn reference point shall be defined in accordance with ITU-T Recommendation 
H.248.1 [2] and shall conform to 3GPP specific extensions as detailed in 3GPP TS 29.332 [15]. 

The present specification describes Mn signalling procedures and their interaction with BICC/ISUP and SIP signalling 
in the control plane, and with user plane procedures. 3GPP TS 29.332 [15] maps these signalling procedures to H.248 
messages and defines the required packages and parameters. 



9.2 IVIn signalling interactions 



The following paragraphs describe the Mn interface procedures triggered by SIP and BICC signalling relayed in 
MGCF. 

The SIP signalling occurring at the MGCF is described in 3GPP TS 24.229 [9]. 

All message sequence charts in this clause are examples. 



9.2.1 



Network model 



Figure 33 shows the network model, applicable to BICC and ISUP cases. The broken line represents the call control 
signalling. The dotted line represents the bearer control signalling (if applicable) and the user plane. The MGCF uses 
one context with two terminations in the IM-MGW. The termination Tl is used towards the IM CN subsystem entity 
and the bearer termination T2 is used for the bearer towards the succeeding CS network element. 
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Figure 33: Network model 



ETSI 



3GPP TS 29.1 63 version 6.1 2.0 Release 6 62 ETSI TS 1 29 1 63 V6.1 2.0 (2009-06) 

9.2.2 Basic IM CN subsystem originated session 
9.2.2.1 BICC forward bearer establishment 

9.2.2.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the CS network side bearer 
establishment. This may happen either before sending the lAM or after receiving the APM message (signal 5 or signal 6 
in figure 34). In the latter case, the IM-MGW selection may be based on a possibly received MGW-id from the 
succeeding node. 

9.2.2.1 .2 CS network side bearer establishment 

The MGCF shall either select bearer characteristics or request the IM-MGW to select and provide the bearer 
characteristics for the CS network side bearer connection before sending the lAM. In the latter case the MGCF shall use 
the Prepare Bearer procedure, not shown in figure 34, to request the IM-MGW to select the bearer characteristics. After 
the succeeding node has provided a bearer address and a binding reference in the APM, the MGCF shall use the 
Establish Bearer procedure to request the IM-MGW to establish a bearer towards the destination CS-MGW. The MGCF 
shall provide the IM-MGW with the bearer address, the binding reference and the bearer characteristics (signal 7 in 
figure 34). 

9.2.2.1 .3 IM CN subsystem side termination reservation 

On receipt of an initial INVITE (signal 1 in figure 34) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 34). From the received SDP and local configuration 
data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW 

Shall reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local 
UDP port and IP address. 

Shall reserve resources for those codec(s). 

The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 9 in figure 
34). 

9.2.2.1 .4 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 10 in figure 34), the MGCF may initiate the 
Configure IMS Resources procedure. If no SDP is received, or if the received SDP does not contain relevant changes 
compared to the previous SDP sent to the IMS in signal 9 in figure 34, the procedure is not invoked. Otherwise the 
MGCF shall use the Configure IMS Resources procedure to provide to the IM-MGW 

The appropriate remote codec(s), the remote UDP port and the remote IP address. 

Optionally the appropriate local codec(s), UDP port and IP address. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 
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The IM-MGW shall: 

Reply to the MGCF with the selected remote codec(s), 

Reply to the MGCF with the selected local codec(s)if the MGCF supplied local codec(s), 

- Update the codec reservation and remote IP address and remote UDP port in accordance with the received 
information. 

The MGCF shall include the selected codec(s) and UDP port and IP address in an 200 OK (PRACK) (signal 1 1 in 
figure 34) sent back to the IMS. 

9.2.2.1.5 Through-connection 

During the Prepare Bearer and Establish Bearer procedures, the MGCF shall either use the Change Through-Connection 
procedure to request the IM-MGW to backward through-connect the BICC terminations, or the MGCF shall use this 
procedure to both-way through-connect the BICC termination already on this stage (signal 7 in figure 34). During the 
Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to 
request the IM-MGW to backward through-connect the IMS termination (signal 3 in figure 34). 

When the MGCF receives the BICC:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the termination using the Change Through-Connection or Change IMS Through-Connection procedures (signal 
22 in figure 34), unless those terminations are already both-way through-connected. 

9.2.2.1.6 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.1 .7 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session, as described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session as described in clause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.2.1 .8 Message sequence chart 

Figure 34 shows the message sequence chart for the IM CN subsystem originating session with BICC forward bearer 
establishment where the selection of IM-MGW is done before the sending of the lAM. In the chart the MGCF requests 
the seizure of an IM CN subsystem side termination. When the APM is received from the succeeding node, the MGCF 
requests the seizure of a CS network side bearer termination and the establishment of the bearer. When the MGCF 
receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. 
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Figure 34: Basic IIVI CN Subsystem originating session, BICC forward bearer establishment 

(message sequence chart) 
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9.2.2.2 BICC backward bearer establishment 

9.2.2.2.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment, and before it sends the lAM (signal 8 in figure 35). 

9.2.2.2.2 IM CN subsystem side termination reservation 

On receipt of an initial INVITE (signal lin figure 35) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 35). From the received SDP and local configuration 
data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s)and request a local IP address and UDP port. The 
local UDP port and IP address are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW shall 

Reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local UDP 
port and IP address. 

Reserve resources for those codec(s). 



The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 5 in figure 
35). 

9.2.2.2.3 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 9 in figure 35) the MGCF may initiate the 
Select Configure IMS Resources procedure (signals 10 and 1 1 in figure 35). If no SDP is received, or if the received 
SDP does not contain relevant changes compared to the previous SDP the procedure is not invoked. Otherwise the 
MGCF shall use the Configure IMS Resources procedure to provide to the IM-MGW. 

the appropriate remote codec(s), the remote UDP port and the remote IP address. 

optionally if DTMF support together with speech support is required, the reserve value indicator shall be set to 
"true". 



The IM-MGW shall: 

Reply to the MGCF with the selected remote codec(s). 

Reply to the MGCF with the selected local codec(s), if the MGCF supplied local codec(s). 

Update the codec reservation and remote IP address and remote UDP port in accordance with the received 
information. 

The MGCF shall include the selected codec(s), IP address and UDP port in an 200 OK (PRACK) (signal 12 in figure 
35) sent back to the IMS 



£75/ 



3GPP TS 29.1 63 version 6.1 2.0 Release 6 66 ETSI TS 1 29 1 63 V6.1 2.0 (2009-06) 

9.2.2.2.4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure before sending the lAM to the succeeding node. Within this procedure, the MGCF shall request the 
IM-MGW to provide a bearer address and a binding reference, and the MGCF shall either provide the IM-MGW with 
the preferred bearer characteristics or it shall request the IM-MGW to select and provide the bearer characteristics 
(signal 6 in figure 35). After the IM-MGW has replied with the bearer address, the binding reference and the bearer 
characteristics (if requested), the MGCF sends the lAM to the succeeding node (signal 8 in figure 35). 

9.2.2.2.5 Through-connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signal 6 in figure 35). During the Reserve IMS Connection 
Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the IM-MGW to 
backward through-connect the IMS termination (signal 3 in figure 35). 

When the MGCF receives the BICC:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change Through-Connection or Change IMS Through-Connection procedures 
(signal 21 in figure 35), unless those terminations are already both-way through-connected. 

9.2.2.2.6 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.2.7 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session as described in clause 9.2.6,. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session, as described in clause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.2.2.8 Message sequence chart 

Figure 35 shows the message sequence chart for the IM CN subsystem originating session with BICC backward bearer 
establishment. In the chart the MGCF requests the seizure of an IM CN subsystem side termination and a CS network 
side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations. 
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Figure 35: Basic IIVI CN Subsystem originating session, BICC bacltward bearer establishment 

(message sequence chart) 
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9.2.2.3 ISUP 

9.2.2.3.1 IM-MGW selection 

The MGCF shall select an IM-MGW with circuits to the given destination in the CS domain before it performs the IM 
CN subsystem session establishment and before it sends the JAM (signal 8 in figure 36). 

9.2.2.3.2 IM CN subsystem side termination reservation 

On receipt of an initial INVITE (signal 1 in figure 36) the MGCF shall initiate the Reserve IMS Connection Point and 
Configure Remote Resources procedure (signal 3 and 4 in figure 36). From the received SDP and local configuration 
data the MGCF 

shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. The 
remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN subsystem. 
The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the IM CN 

subsystem. 

shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW shall 

reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local UDP 
port and IP address. 

reserve resources for those codec(s). 

The MCGF shall send selected local codec(s) and the selected remote codec and the selected local UDP port and IP 
address to the IMS in the Session Progress (signal 5 in figure 36) 

9.2.2.3.3 IM CN subsystem side session establishment 

Dependent on what the MGCF receives in the PRACK message (signal 9 in figure 35) the MGCF may initiate the 
Configure IMS Resources procedure. If no SDP is received, or if the received SDP does not contain relevant changes 
compared to the previous SDP, the procedure is not invoked. Otherwise the MGCF shall use the Configure IMS 
Resources procedure to provide to the IM-MGW 

the appropriate remote codec(s), the remote UDP port and the remote IP address. 

optionally the appropriate local codec(s), UDP port and IP address. 

-If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 



The IM-MGW shall: 

reply to the MGCF with the selected remote codec. 

reply to the MGCF with the selected local codec(s), if the MGCF supplied local codec(s). 

update the codec reservation and remote IP address and UDP port in accordance with the received information. 

The MGCF shall include the selected codec(s) UDP port and IP address in 200 OK (PRACK) (signal 12 in figure 36) 
sent back to the IMS. 
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9.2.2.3.4 CS network side circuit reservation 

The MGCF shall request the IM-MGW to reserve a circuit using the Reserve TDM Circuit procedure. The MGCF sends 
the lAM to the succeeding node including the reserved circuit identity. 

9.2.2.3.5 Through-connection 

During the Reserve TDM Circuit and Reserve IMS Connection Point procedures, the MGCF shall either use the Change 
TDM Through-Connection procedure to request the IM-MGW to backward through-connect the termination, or the 
MGCF shall use this procedure to both-way through-connect the TDM termination already on this stage (signal 6 in 
figure 36). During the Reserve IMS connection Point procedure, the MGCF shall use the Change IMS through- 
connection procedure to request the IM-MGW to backward through-connect the IMS termination (signal 3 in figure 36). 

When the MGCF receives the ISUP:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change IMS Through-Connection or Change TDM Through-Connection procedures 
(signal 21 in figure 36), unless those terminations are already both-way through-connected. 

9.2.2.3.6 Continuity check 

The MGCF may request a continuity check on the connection towards the CS network within the lAM message. In this 
case, the MGCF shall use the Continuity Check procedure towards the IM-MGW to request the generation of a 
continuity check tone on the TDM termination. The IM-MGW shall then use the Continuity Check Verify procedure to 
notify the MGCF of an incoming continuity check tone on the corresponding circuit. In addition to other conditions 
detailed in Section 7, the MGCF shall wait until receiving this notification before sending the COT. (Not depicted in 
figure 36) 

9.2.2.3.7 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.2.3.8 Voice processing function 

A voice processing function located on the IM-MGW may be used to achieve desired acoustic quality on the 
terminations. If the voice processing function is used, the MGCF shall request the activation of it in the termination 
towards the CS network using the Activate TDM Voice Processing Function procedure (signal 23 in figure 36). 

9.2.2.3.9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully session shall be released as 
described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM-MGW the default action by 
the MGCF is to release the session as described in clause 9.2.7. 

9.2.2.3.10 Message sequence chart 

Figure 36 shows the message sequence chart for the IM CN subsystem originating session. In the chart the MGCF 
requests the seizure of an IM CN subsystem side termination and a CS network side bearer termination. When the 
MGCF receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. The 
MGCF requests the possible activation of the voice processing functions for the bearer terminations. 
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Figure 36: Basic IIVI CN Subsystem originating session, ISUP (message sequence chart) 
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9.2.3 Basic CS network originated session 
9.2.3.1 BICC forward bearer establishment 

9.2.3.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 

9.2.3.1 .2 IM CN subsystem side termination reservation 

The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 37). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 4 in figure 37) to the IM CN subsystem. 

9.2.3.1 .3 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 7 and 8 in figure 37) to provide configuration 
data (derived from SDP received in signal 6 in figure 37 and local configuration data) to the IM-MGW as detailed 
below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

IF DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 



The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 6 in figure 37, the MGCF shall send 
the local reserved codec(s), and the local IP address and UDP port in the PRACK (signal 9 in figure 37) to the IMS. 

9.2.3.1 .4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure (signals 1 1 and 12 in figure 37). Within this procedure, the MGCF shall request the IM-MGW to 
provide a bearer address, a binding reference and optionally notify when the bearer is established. The MGCF shall also 
provide the IM-MGW with the bearer characteristics that was received from the preceding node in the lAM. After the 
IM-MGW has replied with the bearer address and the binding reference, the MGCF provides the APM message (signals 
13 in figure 37) to the preceding node. The MGCF may also provide the IM-MGW -id in the APM message. 

9.2.3.1 .5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 20 and 21 in figure 37) , when the first of the following conditions is satisfied: 

the MGCF receives the first 1 80 Ringing message 
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Timer T i/wi expires 
Timer T i/w2 expires 



9.2.3.1 .6 Called party answer 

When the MGCF receives a 200 OK message (signal 23 in figure 34), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 26 and 27 in figure 37). 

9.2.3.1.7 Through-Connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signals 1 1 and 12 in figure 37). During the Reserve IMS 
Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the IM- 
MGW to backward through-connect the IMS termination (signals 2 and 3 in figure 37). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 23 in figure 37), it requests the IM-MGW to both-way 
through-connect the terminations using the Change IMS Through-Connection or Change Through-Connection 
procedures (signals 28 and 29 in figure 37), unless those terminations are already both-way through-connected. 

9.2.3.1.8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.3.1 .9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session, as described in clause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.3.1.10 Message sequence chart 

Figure 37 shows the message sequence chart for the CS network originating session with BICC forward bearer 
establishment. In the chart the MGCF requests the seizure of the IM CN subsystem side termination and CS network 
side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations 
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Figure 37/1 : Basic CS Networit Originating Session, Forward Bearer Establishment (message 

sequence chart) 
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Figure 37/2: Basic CS Networit Originating Session, Forward Bearer Establishment 

(message sequence chart continue) 



9.2.3.2 



BICC Backward bearer establishment 



9.2.3.2.1 



IM-MGW selection 



The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 



9.2.3.2.2 



CS network side bearer establishment 



The MGCF shall request the IM-MGW to establish a bearer using the Establish Bearer procedure (signals 2 and 3 in 
figure 38). The MGCF provides the IM-MGW with the bearer address, the binding reference and the bearer 
characteristics that were received from the preceding node in the lAM (signal 1 in figure 38). 



9.2.3.2.3 



IM CN subsystem side termination reservation 



The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 38). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 6 in figure 38) to the IM CN subsystem. 
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9.2.3.2.4 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 9 and 10 in figure 38) to provide configuration 
data (derived from SDP received in signal 8 in figure 38 and local configuration data) to the IM-MGW as detailed 
below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 



The IM-MGW shall reply with the selected remote codec(s) and reserve resources for this codec. If local codec(s) were 
received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 8 in figure 38, the MGCF shall send 
the reserved speech codec(s), and the local IP address and UDP port in the PRACK (signal 11 in figure 38) to the IMS. 

9.2.3.2.5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 19 and 20 in figure 38) , when the first of the following conditions is satisfied: 

the MGCF receives the first 1 80 Ringing message, 

Timer T i/wi expires. 

Timer T i/w2 expires. 

9.2.3.2.6 Called party answer 

When the MGCF receives a 200 OK message (signal 22 in figure 38), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 23 and 24 in figure 38). 

9.2.3.2.7 Through-Connection 

During the Establish Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to 
request the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to 
both-way through-connect the BICC termination already on this stage (signals 2 and 3 in figure 38). During the Reserve 
IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the 
IM-MGW to backward through-connect the IMS termination (signals 4 and 5 in figure 38). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 22 in figure 38), it shall request the IM-MGW to both-way 
through-connect the bearer using the Change IMS Through-Connection or Change Through-Connection procedure 
(signals 25 and 26 in figure 38), unless those terminations are already both-way through-connected. 

9.2.3.2.8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 
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9.2.3.2.9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session as described in clause 9.2.7. 

Note: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

9.2.3.2.10 Message sequence chart 

Figure 38 shows the message sequence chart for the CS network originating session with BICC backward bearer 
establishment. In the chart the MGCF requests seizure of the IM CN subsystem side termination and CS network side 
bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through- 
connect the terminations. 
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Figure 38/1 : Basic CS Networit Originating Session, BICC Backward Bearer Establishment (message 

sequence chart) 
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Figure 38/2: Basic CS Networit Originating Session, BICC Bacltward Bearer Establishment 

(message sequence chart continue) 



9.2.3.3 



ISUP 



9.2.3.3.1 IM-MGW selection 

The MGCF selects the IM-MGW based on the received circuit identity in the lAM. 

9.2.3.3.2 CS network side circuit reservation 

The MGCF shall request the IM-MGW to reserve a circuit using the Reserve TDM Circuit procedure. 



9.2.3.3.3 



IM CN subsystem side termination reservation 



The MGCF shall derive from configuration data one or several appropriate local codec(s) the IM-MGW may use to 
receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point procedure 
(signals 2 and 3 in figure 39). Within this procedure, the MGCF shall indicate the local codec(s) and request a local IP 
address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM-MGW to receive user 
plane data from the IM CN subsystem. If DTMF support together with speech support is required, or if the resources for 
multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to "true". 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 6 in figure 39) to the IM CN subsystem. 



9.2.3.3.4 



IM CN subsystem side session establishment 



The MGCF shall use the Configure IMS Resources procedure (signals 9 and 10 in figure 39) to provide configuration 
data (derived from SDP received in signal 8 in figure 39 and local configuration data) as detailed below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 
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The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall 
indicate the local codec(s) if a change is required. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to 

"true". 



The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 8 in figure 39, the MGCF shall send 
the reserved speech codec(s), and the local IP address and UDP port in the PRACK (signal 11 in figure 39) to the IMS. 

9.2.3.3.5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send TDM Tone procedure (signals 19 and 20in figure 39) , when the first of the following conditions is 
satisfied: 

the MGCF receives the first 1 80 Ringing message 

Timer T i/wi expires 

Timer T i/w2 expires 

9.2.3.3.6 Called party answer 

When the MGCF receives a 200 OK message (signal 22 in figure 39), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop TDM Tone procedure (signals 23 and 24 in figure 39). 

9.2.3.3.7 Through-Connection 

Within the Reserve TDM Circuit procedure, the MGCF shall either use the Change TDM Through-Connection 
procedure to request the IM-MGW to backward through-connect the TDM termination, or the MGCF shall use this 
procedure to both-way through-connect the TDM termination already on this stage (signals 2 and 3 in figure 39). 
During the Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection 
procedure to request the IM-MGW to backward through-connect the IMS termination (signals 4 and 5 in figure 39). 

When the MGCF receives the SIP 200 OK(INVITE) message, it shall request the IM-MGW to both-way through- 
connect the terminations using the Change IMS Through-Connection or Change TDM Through-Connection procedure 
(signals 25 and 26 in figure 39), unless those terminations are already both-way through-connected. 

9.2.3.3.8 Continuity Check 

If a continuity check on the connection towards the CS network is requested in the lAM message, the MGCF shall use 
the Continuity Check Response procedure towards the IM-MGW to request loop-back of a received continuity check 
tone on the TDM circuit. Upon reception of the COT message, the MGCF shall use the Continuity Check Response 
procedure towards the IM-MGW to request the removal of the loop-back. (Not depicted in figure 39) 

9.2.3.3.9 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

9.2.3.3.10 Voice Processing function 

A voice processing function located on the IM-MGW may be used to achieve desired acoustic quality on the 
terminations. If the voice processing function is used, the MGCF shall request the activation of it in the termination 
towards the CS network using the Activate TDM Voice Processing Function procedure (signal 23 in figure 39). 
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9.2.3.3.1 1 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the session shall be released as 
described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM-MGW the default action by 
the MGCF is to release the session as described in clause 9.2.7. 

9.2.3.3.12 Message sequence chart 

Figure 39 shows the message sequence chart for the CS network originating Session with ISUP. In the chart the MGCF 
requests seizure of the IM CN subsystem side termination and CS network side bearer termination. When the MGCF 
receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. The MGCF may 
request the possible activation of the voice processing functions for the terminations. 
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Configure IMS Resources 



1.ISUP:IAM 



2. H.248 : ADD.req [Context ID = ?, Termination ID = ?] 



3. H.248 : ADD.resp [Context ID = CI , Termination ID = T2] 



4. H.248 : ADD.req [Context ID = C1 , Termination ID=?] 



5. K248: ADD.resp [Context ID = CI, Termination ID = T1] 



9. H.248 : MOD.req [Context ID = CI .Termination ID = T1] 



1 0.hL248: MOD.resp [Context ID = CI , Termination ID = T1 ]_ 



13. ISUP:COT 



18. ISUP: ACM 



19. H.248 : MOD.req [Context ID = CI, Termination ID = T2] 



20. H.248 : MOD.resp [Context ID = CI , Termination ID = T2] 



Reserve TDM Circuit, 
Change Through- 
Connection = both 



Reserve IMS Connection Point, 
Change IMS Through- 
Connection = backward 



6. SIP: INVITE 



7. SIP: 100 Trying 



8. SIP:1 83 Session 
Progress 



11. SIP: PRACK 



12.S1P :200OK(PRACK) 





14. SIP: 


UPDATE 




■4-- 


15. SIP :200 OK (UPDATE! 


16. SIP 


:180 Ringing 




17. SIP 


PRACK 


--► 



Send TDM Tone 



21 . S!P :200 OK (PRACK) 



Figure 39/1 : Basic CS Networit Originating Session, ISUP (message sequence chart) 



£75/ 



3GPP TS 29.163 version 6.12.0 Release 6 



82 



ETSI TS 129 163 V6.12.0 (2009-06) 



IM-MGW 



MGCF 



23. H.248 : MOD.req [Context ID=C1, Termination ID = T2] 



24. H.248 : IVIOD.resp [Context ID = CI, Termination ID = T2] 



25. H.248 : MOD.req [Context ID=C1, Termination ID = T1] 



26. H.248 : MOD. resp [Context ID = CI, Termination ID = T1] 



27. ISUP: ANM 



CALL IN ACTIVE STATE 



22. SIP :200 OK (INVITE] 



Stop TDM Tone , 
Activate TDM Voice 
Processing Function 



Change IMS Through- 
Connection = both 



28. S!P: ACK 



Figure 39/2: Basic CS Networic Originating Session, ISUP (message sequence chart continue) 

9.2.3.4 Handling of Forking 

The procedures described in clauses 9.2.3.1 to 9.2.3.3 shall be applied with the following additions. 



9.2.3.4.1 



Detection of Forking 



According to SIP procedures, the O-MGCF inspects the tags in the 'to' SIP header fields of provisional and final 
responses to identify the SIP dialogue the response belongs to. If responses belonging to different dialogues are 
received (signals 8 and 13 in figure 39a) , the INVITE request (signal 6 in figure 39a) has been forked. 



9.2.3.4.2 



IM CN subsystem side session establishment 



If SDP is received in a provisional response and more than one SIP dialogue exists (signal 13 in figure 39a), the MGCF 
may either refrain from reconfiguring the IM-MGW, or it may use the Configure IMS Resources procedure (signals 14 
and 15 in figure 39a) as detailed below: 

The MGCF may compare the selected local codecs of the different dialogues (which the MGCF selects due to 
the received SDP answer and local configuration data). If different local codecs are selected for the different 
dialogues, the MGCF may include all these codecs in the 'local IMS resources', and set the 'reserve value' to 
indicate that resources for all these codecs shall be reserved. Alternatively, the MGCF may only include the 
codecs received in the last SDP in the 'local IMS resources'. 

The MGCF may update the 'remote IMS resources' with the information received in the latest SDP. The MGCF 
should provide the remote IP address and UDP port, and the remote codec selected from the received SDP and 
local configuration data. 

NOTE: The behaviour in the second bullet is beneficial if forking is applied in a sequential manner. 
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9.2.3.4.3 IM CN subsystem side session establishment completion 

Upon reception of the first final 2xx response (signal 32 in figure 39a), the MGCF shall use the Configure IMS 
Resources procedure (signals 35 and 36 in figure 39a) as detailed below unless the IM-MGW is already configured 
accordingly: 

If the remote IMS resources configured at the IM-MGW do not match the remote resources selected for the 
established dialogue of the final response, the MGCF shall provide the remote IP address and UDP port from the 
latest received SDP of this established dialogue, and the remote codec selected from the latest received SDP of 
this established dialogue and local configuration data within the 'remote IMS resources'. 

If the local IMS resources configured at the IM-MGW contain more codecs than selected for the established 
dialogue of the final response, the MGCF should update the 'local IMS resources' with the selected local codec 
derived from the latest SDP of this established dialogue and local configuration data. The 'reserve value' may be 
cleared unless it is required for DTMF. 

9.2.3.4.4 Message sequence chart 

Figure 39a shows an example message sequence chart for an CS network originating Session Setup with ISUP, where 
forking occurs. 
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Reserve TDM Circuit, 
Change Through- 
Connection = both 



Reserve IIVIS Connection Point, 
Change IIVIS Through- 
Connection = backward 



Configure IMS Resources 



Configure IMS Resources 



1.ISUP:IAM 



2. H.248 : ADD.req [Context ID = ?, Termination ID = ?] 



3. H.248 : ADD.resp [Context ID = CI, Termination ID = T2] 



4. H.248 : ADD.req [Context ID = C1 , Termination ID=?] 



5. K248: ADD.resp [Context ID = CI, Termination ID = T1] 



9. H.248 : MOD.req [Context ID = C1 ,Termination ID = T1] 



1 0.hL248: MOD.resp [Context ID = C1 , Termination ID = T^ 



14. H.248 : MOD.req [Context ID = CI, Termination ID = T1] 



1 5.hL248: MOD.resp [Context ID = C1 , Termination ID = T1 ]_ 16. SIP: 



18. ISUP:COT 



6. SIP: INVITE 



7. SIP: 100 Trying 



8. SIP:1 83 Session 

Progress 
(to:xxx, tagA) 



1 1 . S!P: PRACK 
(to:xxx, tagA) 



12. SIP :200 OK (PRACKl 
(to:xxx, tagA) 



13. S!P: 183 Session 

Progress 

(to:xxx, tagB) 



16. SIP: PRACK 
(to:xxx, tagB) 



17.S1P :200OK{PRACK) 
(to:xxx, tagB) 



19. SIP: UPDATE 
(to:xxx, tagA) 



20. S!P: UPDATE 
(to:xxx, tagB) 



21 . S!P :200 OK (UPDATE) 
(to: XXX,, tagA) 



22. S!P :200 OK (UPDATE) 
(to: XXX,, tagB) 



Figure 39a/1 : CS Network Originating Session with foriting, ISUP (message sequence chart) 
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IM-MGW 



Stop TDM Tone , 
Activate TDM Voice 
Processing Function 



Configure IMS 
Resources, 
Change IMS Through- 
Connection = both 



MGCF 



26. ISUP: ACM 



27. H.248 : MOD.req [Context ID = CI, Termination ID = T2 



28. H.248 : MOD.resp [Context ID = C1 , Termination ID = T2; 



33. H.248 : MOD.req [Context ID=C1, Termination ID = T2] 



34. H.248 : MOD.resp [Context ID = C1 , Termination ID = T2; 

1 



35. H.248 : MOD.req [Context ID=C1, Termination ID = T1] 



36. H.248 : MOD.resp [Context ID = C1 , Termination ID = T1 



37. ISUP: ANM 



23. S!P :180 Ringing 
(to:xxx, tagB) 

24. S!P: PRACK 
(to:xxx, tagB) 



25. S!P :200 OK (PRACK) 
(to:xxx, tagB) 



Send TDM Tone 



29. S!P :180 Ringing 
{to:xxx, tagA) 



30. S!P: PRACK 
(to:xxx, tagA) 



31 . S!P :200 OK (PRACK) 
(to:xxx, tagA) 



32. SIP :200 OK (INVITE) 
(to:xxx, tagA) 



38. S!P: ACK 



CALL IN ACTIVE STATE 



Figure 39a/2: CS Network Originating Session with forlting, ISUP (message sequence chart continue) 
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9.2.4 Session release initiated from IM CN subsystem side 

9.2.4.1 BICC 



9.2.4.1.1 



Session release in the IM CN subsystem side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall release resources in 
the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 
5 and 6 in figure 40). After receiving the BYE message, the MGCF shall also send a 200 OK [BYE] message towards 
the IM CN subsystem (signal 2 in Figure 40). 



9.2.4.1.2 



Session release in the CS network side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall send a REL message 
to the succeeding node (signal 3 in figure 40). Once the succeeding node has responded with the RLC message (signal 6 
in figure 40), the MGCF shall release the resources for the CS network side in the IM-MGW. If any resources were 
seized in the IM-MGW, the MGCF shall use the "Release Bearer", "Change Through-Connection" and "Release 
Termination" procedures (signals 7 to 10 in figure 40) to indicate to the IM-MGW that the CS network side bearer 
termination shall be removed and the bearer shall be released towards the succeeding MGW. 

9.2.4.1 .3 Message sequence chart 

Figure 40 shows the message sequence chart for the session release initiated from the IM CN subsystem side. 



MGCF 



1. SIP: BYE 



2. S!P: 200 OK [BYE] 



Release IMS Termination 



Release Bearer, 
Change Through- 
Connection = backward 



Release Termination 



IM-MGW 



3. BICC: REL 



4. BICC : RLC 



5. H.248 : SUB.req [Context ID = C1 , Termination ID = T1] 



6. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



7. H.248 : MOD.req [Context ID = CI, Termination ID = T2] 



8. H.248 : IVIOD.resp [Context ID = C1, Termination ID = T2] 



9. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



10. tL248: SUB.resp [Context ID = CI, Termination ID = T2] 



Figure 40: Session release from IIUI CN subsystem side for BICC (message sequence chart) 
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9.2.4.2 



ISUP 



9.2.4.2.1 



Session release in the IM CN subsystem side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall release resources in 
the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 
4 and 5 in figure 41). After receiving the BYE message, the MGCF shall also send a 200 OK [BYE] message towards 
the IM CN subsystem (signal 2 in figure 41). 



9.2.4.2.2 



Session release in the CS network side 



When the MGCF has received a BYE message from the IM CN subsystem side, the MGCF shall send a REL message 
to the succeeding node (signal 3 in figure 41). After sending the REL message, the MGCF shall expect a RLC message 
(signal 8 in figure 41) from the succeeding node. The MGCF shall also release the resources for the CS network side in 
the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use the "Release TDM Termination" 
procedure (signals 6 to 7 in figure 41) to indicate to the IM-MGW that the CS network side bearer termination can be 
released. 

9.2.4.2.3 Message sequence chart 

Figure 41 shows the message sequence chart for the session release initiated from the IM CN subsystem side. 



MGCF 



1. SIP: BYE 



2. S!P: 200 OK [BYE] 



Release IMS Termination 



Release TDM Termination 



3. ISUP: REL 



4. H.248 : SUB.req [Context ID = C1, Termination ID = T1] 



5. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



6. H.248 : SUB.req [Context ID = C1 , Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2] 



8. ISUP: RLC 



Figure 41 : Session release from IM CN subsystem side for ISUP (message sequence chart) 

9.2.5 Session release initiated from CS network side 



9.2.5.1 



BICC 



9.2.5.1.1 



Session release in the CS network side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 42), the MGCF shall release 
resources for the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use 
the "Release Bearer", "Change Through-Connection" and "Release Termination" procedures to indicate to the IM- 
MGW that the CS network side bearer termination shall be removed and the bearer shall be released towards the 
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preceding MGW (signal 3 to 6 in figure 42). After completion of resource release, the MGCF shall send a RLC message 
towards the preceding node. 



9.2.5.1.2 



Session release in the IM CN subsystem side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 42), the MGCF shall send a BYE 
message to the IM CN subsystem (signal 2 in figure 42) and the MGCF shall release the resources in the IM-MGW 
serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 7 and 8 in 
figure 42). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 10 
in figure 42). 

9.2.5.1 .3 Message sequence chart 

Figure 42 shows the message sequence chart for the session release initiated from the CS network side. 



Release Bearer, 
Change Through- 
Connection = backward 



Release Termination 



Release IMS 
Termination 



1 .BICC: REL 



3. H.248 : MOD.req [Context ID = C1 , Termination ID = T2] 



4. H.248 : MOD.resp [Context ID =C1 , Termination ID =T2] 



5. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



6. H.248 : SUB.resp [Context ID =C1 , Termination ID =T2 ] 



7. H.248 : SUB.req [Context ID = C1 , Termination ID = T1] 



8. H.248 : SUB.resp [Context ID = C1, Termination ID = T1] 



9. BICC : RLC 



2. SIP: BYE 



10. S!P: 200 OK [BYE] 



Figure 42: Session release from CS networit side for BICC (message sequence chart) 



9.2.5.2 



ISUP 



9.2.5.2.1 



Session release in the CS network side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 43), the MGCF shall release 
resources for the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use 
the "Release TDM Termination procedures" to indicate to the IM-MGW that the CS network side bearer termination 
can be released (signal 3 to 4 in figure 43). After completion of resource release, the MGCF shall send a RLC message 
towards the preceding node. 



9.2.5.2.2 



Session release in the IM CN subsystem side 



When the MGCF receives a REL message from the preceding node (signal 1 in figure 43), the MGCF shall send a BYE 
message to the IM CN subsystem (signal 2 in figure 43) and the MGCF shall release the resources in the IM-MGW 
serving the relevant Mb interface connection by using the "Release IMS Termination" procedure (signal 5 to 6 in figure 
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43). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 8 in 
figure 43). 

9.2.5.2.3 Message sequence chart 

Figure 43 shows the message sequence chart for the session release initiated from the CS network side. 





IM-MGW 




MGCF 










1.ISUP: REL 












3. H.248: SUB.req [Context ID = C1 .Termination ID = T2] 


2. SIP: BYE 






Release TDM 
Termination 


4. H.248: SUB.resp [Context ID = C1 . Termination ID = T21 






5. H.248: SUB.req [Context ID = CI. Termination ID = T11 




Release IMS 
Termination 


6. H.248: SUB.resp [Context ID =C1, Termination ID =T1] 






7. ISUP: RLC 










^ 8. SIP: 200 OK IBYEI 









Figure 43: Session release from CS network side for ISUP (message sequence chart) 

9.2.6 Session release initiatecJ by MGCF 

9.2.6.1 BICC 



9.2.6.1.1 



Session release in the CS network side 



The MGCF shall send a REL message to the succeeding node on the CS network side (signal 1 in figure 44) Once the 
succeeding node has responded with the RLC message (signal 3 in figure 44), the MGCF shall release the resources for 
the CS network side in the IM-MGW. If any resources were seized in the IM-MGW, the MGCF shall use the "Release 
Bearer", "Change Through-Connection" and "Release Termination" procedures to indicate to the IM-MGW that the CS 
network side bearer termination shall be removed and the bearer shall be released towards the succeeding MGW (signal 
4 to 7 in figure 44). 



9.2.6.1.2 



Session release in the IM CN subsystem side 



The MGCF shall sends a BYE message to the IM CN subsystem side (signal 2 in figure 44) and the MGCF shall release 
the resources in the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" 
procedure (signals 8 and 9 in figure 44). The MGCF shall also expect to receive a 200 OK [BYE] message is received 
from the IM CN subsystem side (signal 10 in figure 44). 

9.2.6.1 .3 Message sequence chart 

Figure 44 shows the message sequence chart for the session release initiated by the MGCF. 
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2. S!P: BYE 



Release Bearer, 
Change Through- 
Connection = backward 



Release Termination 



Release IMS 
Termination 



10. S!E: 200 OK [BYE] 



1. BICC: REL 



3. BICC: RLC 



4. H.248 : MOD.req [Context ID = C1 , Termination ID = T2] 



5. H.248 : MOD.resp [Context ID = CI, Termination ID = T2] 



6. H.248 : SUB.req [Context ID = C1, Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2 ] 



8. H.248 : SUB.req [Context ID = CI, Termination ID = T1] 



9. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



Figure 44: Session release initiated by MGCF for BICC (message sequence chart) 



9.2.6.2 



ISUP 



9.2.6.2.1 



Session release in the CS network side 



The MGCF shall send a REL message to the succeeding node on the CS network side (signal 2 in figure 45) and the 
MGCF shall release the resources for the CS network side in the IM-MGW. If any resources were seized in the IM- 
MGW, the MGCF shall use the "Release TDM Termination" procedure to indicate to the IM-MGW that the CS network 
side termination shall be released (signal 5 to 6 in figure 45). The MGCF shall also expect to receive a RLC message 
from the succeeding node on the CS network side (signal 7 in figure 45). 



9.2.6.2.2 



Session release in the IM CN subsystem side 



The MGCF shall send a BYE message to the IM CN subsystem side (signal 1 in figure 45) and the MGCF shall release 
the resources in the IM-MGW serving the relevant Mb interface connection by using the "Release IMS Termination" 
procedure (signal 5 to 6 in figure 45). The MGCF shall also expect to receive a 200 OK [BYE] message from the IM 
CN subsystem side (signal 8 in figure 45). 

9.2.6.2.3 Message sequence chart 

Figure 45 shows the message sequence chart for the session release initiated by the MGCF. 
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MGCF 



1. SIP: BYE 



Release IMS 
Termination 



Release TDM 
Termination 



8. S!P: 200 OK [BYE] 



IM-MGW 



2. ISUP: REL 



3. H.248 : SUB.req [Context ID = C1, Termination ID = T1] 



4. H.248 : SUB.resp [Context ID = C1 , Termination ID = T1] 



5. H.248 : SUB.req [Context ID = C1 .Termination ID = T2] 



6. H.248 : SUB.resp [Context ID = C1 , Termination ID = T2 ] 



7. ISUP: RLC 



Figure 45: Session release initiated by IVIGCF for ISUP (message sequence chart) 

9.2.7 Session release initiated by IM-MGW 
9.2.7.1 BICC 



9.2.7.1.1 



Session release in the CS network side 



Upon receiving from the IM-MGW a "Bearer Released" procedure (signal la and 2a in figure 46) or IMS Bearer 
Released' procedure (signal lb and 2b in figure 46) or a "MGW Out-of-Service" procedure indicating an immediate 
release (H248 ServiceChangeMethod="Forced") (not depicted in figure 46), the MGCF shall send a REL message to 
the succeeding node on the CS network side (signal 3 in figure 46). Once the succeeding node has responded with the 
RLC message (signal 5 in figure 46), the MGCF shall release the resources for the CS network side in the IM-MGW, 
unless the "MGW Out-of-Service" procedure was received.. If any resources were seized in the IM-MGW, the MGCF 
shall use the "Release Termination" procedure to indicate to the IM-MGW that the CS network side bearer termination 
shall be removed (signals 6 and 7 in figure 46). 

Note: Other actions related to MGW Out-Of-Service procedure is defined in 3GPP TS 23.205 [27]. 



9.2.7.1.2 



Session release in the IM CN subsystem side 



Upon receiving from the IM-MGW a "Bearer Released" procedure (signals la and 2a in figure 46) or IMS Bearer 
Released' procedure (signal lb and 2b in figure 46) or a "MGW Out-of-Service" procedure indicating an immediate 
release (H248 ServiceChangeMethod="Forced") (not depicted in figure 46), the MGCF shall send a BYE/CANCEL 
message to the IM CN subsystem side (signal 4 in figure 46) Upon receiving from the IM-MGW a "Bearer Released" 
procedure or 'IMS Bearer Released' procedure, the MGCF shall also release the resources in the IM-MGW serving the 
relevant Mb interface connection by using the "Release IMS Termination" procedure (signals 8 and 9 in figure 46). The 
MGCF shall also expect to receive a 200 OK [BYE] message from the IM CN subsystem side (signal 10 in figure 46). 

NOTE: Other actions related to MGW-Out-Of-Service procedure is defined in 3GPP TS 23.205 [27] 

9.2.7.1 .3 Message sequence chart 

Figure 46 shows the message sequence chart for the session release initiated by the IM-MGW. 
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Bearer Released 



IMS Bearer 
Released 



4. SIP: BYE 



MGCF 



Release Termination 



Release IMS Termination 



10.S!P:200OK[BYE] 



IM-MGW 



1 a. H.248 : Notify.req [Context ID = C1 , Termination ID = T2] 



2a. H.248 : Notify.resp [Context ID = C1 , Termination ID = 12] 



1b. H.248 : Notify.req [Context ID = CI, Termination ID = T1] 



2b. H.248 : Notify.resp [Context ID = CI, Termination ID = T1] 



3. BICC: REL 



5. BICC: RLC 



6. H.248 : SUB.req [Context ID = CI, Termination ID = T2] 



7. H.248 : SUB.resp [Context ID = CI , Termination ID = T2 ] 



8. H.248 : SUB.req [Context ID = CI, Termination ID = T1] 



9. H.248 : SUB.resp [Context ID = CI, Termination ID = T1] 



Figure 46: Session release initiated by the IM-MGW for BICC (message sequence chart) 



9.2.7.2 



ISUP 



9.2.7.2.1 



Session release in the CS networl< side 



Upon receiving from the IM-MGW a "Termination Out-of-Service" procedure indicating an immediate release (signals 
la and 2a in figure 47), a "Bearer Released" procedure (signal lb and 2b in figure 47), a 'IMS Bearer Released' 
procedure (signal Ic and 2c in figure 47) or a "MGW Out-of-Service procedure" (not depicted in figure 47) indicating 
an immediate release (H248 ServiceChangeMethod="Forced") the MGCF shall send a REL message to the succeeding 
node (signal 3 in figure 47). Upon receiving from the IM-MGW a "Termination Out-of-Service" message procedure 
indicating an immediate release or a "Bearer Released" procedure, the MGCF shall also release the resources for the 
corresponding CS network side termination(s) in the IM-MGW. If any resources were seized in the IM-MGW, the 
MGCF shall use the "Release TDM Termination" procedure to indicate to the IM-MGW that the CS network side 
bearer termination can be removed (signals 7 and 8 in figure 47). The MGCF also expects to receive a RLC message on 
the CS network side (signal 9 in figure 47) before the circuit is reselectable. 

Note: Other actions related to "MGW-Out-Of-Service" procedure is defined in 3GPP TS 23.205 [27]. 



9.2.7.2.2 



Session release in the IM CN subsystem side 



Upon receiving from the IM-MGW a "Termination Out-of-Service" procedure indicating an immediate release (signal 
la and 2a in figure 47) on the CS termination in the context, a "Bearer Released" procedure (signal lb and 2b in figure 
47), an 'IMS Bearer Released' procedure (signal Ic and 2c in figure 47) or a "MGW Out-of-Service procedure" (not 
depicted in figure 47) indicating an immediate release, (H248 ServiceChangeMethod="Forced") the MGCF shall send a 
BYE/CANCEL message to the IM CN subsystem side (signal 4 in figure 47). Upon receiving from the IM-MGW a 
"Termination Out-of-Service" procedure indicating an immediate release on the CS termination in the context, a 
"Bearer Released" procedure or an 'IMS Bearer Released' procedure, the MGCF shall also release the resources in the 
IM-MGW for the corresponding terminations towards the IM CN subsystem using the "Release IMS Termination" 
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procedure (signals 5 and 6 in figure 47). The MGCF also expects to receive a 200 OK [BYE] message from the IM CN 
subsystem side (signal 10 in figure 47). 

NOTE: Other actions related to 'MGW-Out-Of-Service' procedure is defined in 3GPP TS 23.205 [27]. 

9.2.7.2.3 Message sequence chart 

Figure 47 shows the message sequence chart for the session release initiated by the IM-MGW. 



Termination 
Out-of-Service 



or 
Bearer Released 

or 

IIVIS Bearer 
Released 

4. SIP: BYE 



Release IMS 
Termination 



Release TDM 
Termination 



10.S!P:200OK[BYE] 



IM-MGW 



1 a. H.248 : ServiceChange.req 
[Context ID = 01 , Termination ID = T2] 



2a. H.248 : ServiceChange.resp 
[Context ID = C1 , Termination ID = T2] 



1 b. H.248 : Notify.req [Context ID = C1 , Termination ID = T2] 



2b. H.248 : Notify.resp [Context ID = C1 , Termination ID = T2] 



1c. H.248 : Notify.req [Context ID = CI , Termination ID = T1] 



2c. H.248 : Notify.resp [Context ID = CI, Termination ID = T1] 



3. ISUP: REL 



5. H.248 : SUB.req [Context ID = CI , Termination ID = T1 ] 



6. H.248 : SUB.resD [Context ID = CI, Termination ID = T1] 



7. H.248 : SUB.req [Context ID = CI .Termination ID = T2] 



8. H.248 : SUB.resp [Context ID = CI , Termination ID = T2 ] 



9. ISUP: RLC 



Figure 47: Session release initiated by the IIUI-IVIGW for ISUP (message sequence chart) 



9.2.8 Handling of RTP telephone events 

DTMF digits, telephony tones and signals (telephone events) can be transferred using different mechanisms. For the IM 
CN Subsystem, 3GPP TS 24.229 [9] defines the usage of the RTP payload format defined for DTMF Digits, Telephony 
Tones and Telephony Signals in RFC 2833 [34]. When BICC signalling is used in the CS network, telephony signals 
may be sent either inband or out-of-band as defined in ITU-T Recommendation Q. 1902.4 [30] and in ITU-T 
Recommendation Q.765.5 [35]. If ISUP signalling is used the DTMF tones are sent inband. The following paragraphs 
describe the Mn interface procedures to transfer DTMF between RTP format defined in RFC 2833 [34] and the CS CN. 

Before the actual usage of the telephony signals can occur the sending/receiving of telephone events need to be agreed 
with the SDP offer-answer mechanism defined in RFC 3264 [36]. The outcome of the negotiation can be e.g. that no 
telephone events are sent in RTP payload, telephone events are sent only in one direction or in both directions. If the 
outcome of the negotiation is that RTP payload telephone-events are sent in both directions, the IM-MGW may 
nevertheless be configured to interwork only mobile originated telephone-events. 

When the offer-answer mechanism based session parameters negotiation results in an agreement that telephone events 
are sent in the RTP payload and the needed preconditions are fulfilled, telephone events can be sent in RTP payload. 
This negotiation can be done at call control signalling phase or during an ongoing call. 
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If the MGCF and IM-MGW support the reception and/or transmission of the RTP MIME type "telephone event" (as 
defined in RFC 2833 [34]) with the IMS, the following appUes: 

For CS Network Originating Sessions, the MGCF shall include the MIME type "telephone events" with default 
events in the first SDP offer. After the usage of telephone events is agreed in the subsequent offer-answer 
parameter exchanges and the needed preconditions defined in RFC 3312 [37] are fulfilled, telephone events can 
be sent as RTP payload. 

In case of IM CN Subsystem Originating Sessions, the MGCF shall accept the MIME type "telephone events" 
with default events in any SDP answer when it received such an offer. 

9.2.8.1 Sending DTMF digits out-of-band to CS CN (BICC) 

For the IM CN subsystem terminated session , the MGCF shall use the "Configure IMS Resources" procedure as 
described in Clause 9.2.3. For the IM CN subsystem originating session , the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in Clause 9.2.2. If DTMF is supported, the 
MGCF shall include "telephone event" along with the selected speech codecs within the "local IMS resources" 
Parameter of these procedures. The same termination shall be used to receive and transmit DTMF and speech of the 
same call. 

Furthermore, the MGCF shall use the "Detect IMS RTP Tel Signal" procedure to request the MGW to detect incoming 
telephone events from the IMS and notify the MGCF about the detected events. The MGW shall use the "Notify IMS 
RTP Tel Event" procedure for this notification. The termination used to receive DTMF shall be placed in the same 
context used for the speech of the same call. If the IM-MGW received a "Detect IMS RTP Tel Event" procedure for a 
termination, the IM-MGW shall not forward inband to the CS network any DTMF received at this termination. 

Figure 48 shows the message sequence chart when DTMF digits are received from the IM CN subsystem in the RTP 
payload. For the first digit, the received RTP message contains all information including the duration and only a single 
notification is received. For the second digit, the start and the end of the DTMF digit are notified separately. 
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IM-MGW 



Configure IMS Resources 

or 

Reserve IMS Conection Point 

and configure Remote 

Resources, 

Detect IMS RTF Tel Event 



Notify_IMS_RTP_Tel_Event 



Notify_IMS_RTP_Tel_Event 



Notify_IMS_RTP_Tel_Event 



MGCF 



1.H.248Add/Mod.req 

[Context ID = CI , Termination ID = T1 , 
Codec = "telephone event, AMR", 
Notify IMS RTP Tel Event ("Start tone detected", 
"End tone detected") ] 



2. H.248 Add/Mod. resp [Context ID = C1 . Termination ID =T1 L 



3. RTP encoded new DTMF event 
(tone-event, end=1, duration) 



4. H.248 Notify.ind 

[Context ID = C1, Termination ID = T1, Tone-Id, 
Event="Start tone detected", "End tone detected". 
Duration] 



5. H.248 Notify.resp[Context ID = CI , Termination ID = T1] 



6. BICC APM(Actlnd=Start signal notify, signal-type, duration) 



7. BICC APM (Actlnd=Start signal ack) 



8. RTP encoded new DTMF event 

(tone-event, end=0, duration) 



9. H.248 Notify.ind 

[ Context ID = CI , Termination ID = T1 , Tone_ID, 
Event="Start tone detected"! ^ 



, 10. H.248 Notify.resp[Context ID = C1, Termination ID = T1] 



1 1 . BICC APM (Actlnd=Start signal notify, signal-type) 



12. BICC APM (Actlnd=Start signal ack) 



13. RTP encoded continued DTMF event 
(tone-event, end=1 , duration) 



14. H.248 Notify.ind 

[Context ID = CI , Termination ID = T1 , Tone-ID, 
Event="End tone detected". Duration] 



. 15. H.248 Notifv.resp[Context ID = CI, Termination ID = Tl] 



16. BICC APM (Actlnd^Stop signal notify) 



17. BICC APM (Actlnd=Stop signal ack) 



> 



Digit 1 



Digit 2 



Figure 48: Activation of notification of DTIVIF digits received in RTP and examples of sending the 
digits out-of-band to CS CN (message sequence chart) 

9.2.8.2 Sending and receiving DTMF digits inband to/from CS CN (ISUP or BICC) 

For the IM CN subsystem terminated session, the MGCF shall use the "Configure IMS Resources" procedure as 
described in Clause 9.2.3. For the IM CN subsystem originating session , the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in Clause 9.2.2. If DTMF is supported, the 
MGCF shall include "telephone event" along with the selected speech codecs within the "local IMS resources" 
parameter of these procedures to request the MGW to detect incoming telephone events and transform them into speech 
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signals on the CS side. When receiving this configuration, the MGW may in addition optionally detect incoming 
telephone events received inband from the CS CN network and transform them into telephone events on the IMS side. 
The same termination shall be used to receive and transmit DTMF and speech of the same call. 

Figure 49 shows the message sequence chart to configure the IM-MGW to receive DTMF detection on the IMS side 
and transfer the DTMF inband on the CS side. When receiving this configuration, the IM-MGW may in addition 
optionally detect DTMF inband on the CS side and transmit DTMF on the IMS side. 



Configure IMS Resources 

Or 

Reserve IMS Conection Point 

and configure Remote 

Resources 



IM-MGW 




MGCF 




1. H.248 Add/Mod. req 

[Context ID = C1 , Termination ID = 11 , 

Codec = "telephone event, AMR",] 




Dint 


2. H.248 Add/Mod. resp [Context ID = C1 , Termination ID = T1] 










w 





Figure 49: Activation of processing of DTIVIF digits received in RTP for sending the digits inband to 

CS CN (message sequence chart) 



9.2.8.3 



Receiving DTIVIF digits out-of-band from CS CN (BICC) 



For the IM CN subsystem terminated session , the MGCF shall use the "Configure IMS Resources" procedure as 
described in Clause 9.2.3. For the IM CN subsystem originating session , the MGCF shall use the "Reserve IMS 
Connection Point and Configure Remote Resources" procedure as described in Clause 9.2.2. If DTMF is supported, the 
MGCF shall include "telephone event" along with the selected speech codecs within the "local IMS resources" 
Parameter of these procedures. The same termination shall be used to receive and transmit DTMF and speech of the 
same call. 

Furthermore, the MGCF shall use the 'Send IMS RTP Tel Event' and 'Stop IMS RTP Tel Event' procedures to request 
the MGW to play out DTMF to the IM CN subsystem whenever it receives out-of-band DTMF indications from the 
BICC network. 

Figure 49a shows the message sequence chart when DTMF digits are transmitted to the IM CN subsystem in the RTP 
payload. For the first digit, the received APM message contains all information including the duration and only a single 
notification is received. For the second digit, the start and the end of the DTMF digit are notified separately. 
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IM-MGW 



Configure IMS Resources 

or 

Reserve IMS Conection Point 

and configure Remote 

Resources, 

Detect IMS RTF Tel Event 



Send IMS RTP Tel Event 



Send IMS RTP Tel Event 



Stop_IMS_RTP_Tel_Event 



MGCF 



1.H.248Add/Mod.req 

[Context ID = C1 , Termination ID = T1 , 
Codec = "telephone event, AMR", 
Notify IMS RTP Tel Event ("Start tone detected", 
"End tone detected") ] 



2. H.248 Add/Mod. resp [Context ID = CI. Termination ID =T1 L 



3. BICC APM{Actlnd=Start signal notify, signal-type, duration) 



4. BICC ARM (Actlnd=Start signal ack) 



5. H.248 Mod.ind 

[Context ID = C1, Termination ID = T1, Tone-Id, 
Duration! 



6. H.248 Mod.resp[Context ID = CI , Termination ID = T1] 



7. RTP encoded new DTMF event 
(tone-event, end=1, duration) 



8. BICC ARM (Actlnd=Start signal notify, signal-type) 



9. BICC ARM (Actlnd=Start signal ack) 



10. H.248 Mod.ind 

[Context ID = C1, Termination ID = T1, ToneJD, 
^ Duration] 



11. H.248 Mod.resp[Context ID = C1, Termination ID = T1] 



12. RTP encoded new DTMF event 
(tone-event, end=0, duration) 



13. BICC ARM (Actlnd=Stop signal notify) 



14. BICC ARM (Act!nd=Stop signal ack) 



15. H.248 Mod.ind 

[Context ID = CI , Termination ID = T1 , Tone-ID, 
Duration] 



16. H.248 Mod.resp[Context ID = CI, Termination ID = T1] 



17. RTP encoded continued DTMF event 
(tone-event, end=1 , duration) 



Figure 49a: Examples of receiving DTMF digits out-of-band from the CS CN 
and transmitting them in RTP (message sequence chart) 

9.2.9 Session holcJ initiated from IM CN subsystem 

Tlie network model in the clause 9.2. 1 shall apply here. 
Hold request 



Digit 1 



Digit 2 
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When the IMS network makes a hold request by sending an UPDATE or re-INVITE message (signal 1 of figure 50), 
the MGCF shall request the IM-MGW to suspend sending media towards the IMS side by changing the through- 
connection of the IM CN subsystem side termination to 'not through-connected' (signal 2 of figure 50). If the IMS side 
provides modified SDP RR or RS bandwidth modifiers, as specified in IETF RFC 3556 [59], within the hold request, 
the MGCF shall use the Configure IMS Resources Mn procedure to forward this information to the IM-MGW (not 
depicted in figure 50, but may be combined with signal 2). The MGCF shall send a CPG (Hold) message to the 
succeeding CS network node to indicate that the session is on hold (signal 4 of figure 50). Simultaneously a SIP 
message acknowledging the Hold request is sent to the IMS side (signal 7 of figure 50, acknowledged by signal 7. a if 
the INVITE method is used). Announcements may be applied to the party on hold, depending on the held party"s status, 
using the Play Announcement procedure (for BICC) or the Play TDM Announcement procedure (for ISUP, signal 5 in 
figure 50). The hold operation shall not block RTCP flows. 

Resume request 

When the IMS network makes a request to retrieve the session on hold by sending an UPDATE or re-INVITE message 
(signal 8 of figure 50), the MGCF shall request the IM-MGW to re-establish communication towards the IMS network 
by changing the through-connection of the IM CN subsystem side termination to both- way through-connected (signal 
11 of figure 50). If the IMS side provides modified SDP RR or RS bandwidth modifiers, as specified in IETF RFC 3556 
[59], within the retrieve request, the MGCF shall use the Configure IMS Resources Mn procedure to forward this 
information to the IM-MGW (not depicted in figure 50, but may be combined with signal 1 1). Possible announcements 
to the party on hold shall be stopped using the Stop Announcement procedure (for BICC) or the Stop TDM 
Announcement procedure (for ISUP, signal 9 in figure 50). The MGCF shall send a CPG (Retrieve) message to the 
succeeding CS network node to indicate that the session is retrieved (signal 13 of figure 50). 

Message sequence chart 

Figure 50 shows the message sequence chart for the call hold and retrieval procedures. 
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MGCF 




IM-MGW 




1.S1P: UPDATE/INVITE SDP, 
a=sendonly/inactive 














Change Through- 

rinnnprtinn— Inapt ivp 


2. H.248: MOD.rec 

[Context ID = C1, Termination ID = T1] 






3. H.248: MOD.resp 

[Context ID = C1, Termination ID = T1] 








4. BICC/ISUP: CPG (Hold) 




Play TDM 


5. H.248: MOD.req 

[Context ID = C1 , Termination ID = T2] 


■ 




Announcement 


6. H.248: MOD.resp 

[Context ID = C1 , Termination ID = T2] 






7. SIP;200OKfSDPl 


9. H.248: MOD.req 

[Context ID = C1 , Termination ID = T2] 




7.a SIP: ACK (if INVITE is used) 




8. SIP: UPDATE/INVITE [SDP, 
a=se nd recv/recvon ly] 








Stop TDM 
Announcement 


10. H.248: MOD.resp 

[Context ID = CI , Termination ID = T2] 








11. H.248: MOD.req 

[Context ID = CI, Termination ID = T1] 






Change Through- 
Connection=Both 


12. H.248: MOD.resp 

[Context ID = CI, Termination ID = T1] 






13. BICC/ISUP: CPG (Retrieve) 




14. SIP: 200 OK [SDP] 










14.a SIP: ACK (if INVITE is used) 






^^ 





Figure 50 Session hold from ilV! CN subsystem 

9.2.10 Session hold initiated from CS network 

When an MGCF receives a CPG message with a "remote hold" Generic notification indicator (signal 1 of figure 51), the 
MGCF forwards the hold request by sending an UPDATE or re-INVITE message containing SDP with 'sendonly' or 
'inactive' media (signal 4 of figure 51). 

When an MGCF receives a CPG message with a "remote retrieval" Generic notification indicator (signal 6 of figure 
51), the MGCF forwards the resume request by sending an UPDATE or re-lNVlTE message containing SDP with 
'sendrecV or 'recvonly' media (signal 9 of figure 51). 

If the MGCF receives a CPG with "remote hold" or "remote retrieval" before answer, it shall forward the request using 
an UPDATE message. If the MGCF receives a CPG with "remote hold" or "remote retrieval" after answer, it should 
forward the request using re-lNVlTE but may use UPDATE. 

If link aliveness information is required at the IM-MGW while the media are on hold, the MGCF should provide to the 
modified SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] within the SDP offers in the UPDATE 
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or re-INVITE messages holding and retrieving the media to temporarily enable RTCP while the media are on hold, as 
detailed in Clause 7.4 of 3GPP TS 26.236 [32]. If no Hnk aliveness information is required at the IM-MGW, the MGCF 
should provide the SDP RR and RS bandwidth modifiers previously used. 

The interworking does not impact the user plane, unless the MGCF provides modified SDP RR and RS bandwidth 
modifiers in the UPDATE or re-INVITE messages. If the MGCF provides modified SDP RR and RS bandwidth 
modifiers in the UPDATE or re-INVITE messages, the MGCF shall also provide modified SDP RR and RS bandwidths 
to the IM-MGW using the Configure IMS Resoureces procedures (signals 2-3 and 7-8 of figure 51). 

Message sequence chart 

Figure 5 1 shows the message sequence chart for the call hold and retrieval procedures. 



MGCF 



1. BICC/ISUP : CPG (Hold) 



Configure IMS 

Resources 

(optional) 



6. BICC/ISUP : CPG (Retrieve) 



Configure IMS 

Resources 

(optional) 



IM-MGW 



2. H.248 : MOD.rec 

[Context ID = CI , Termination ID = T1] 



3. H.248 : MOD.resp 

[Context ID = C1, Termination ID =T1] 



4. S!P: UPDATE/INVITE [SDP, a=sendonly/inactive] 



5. S!P: 200 OK [SDP] 



5.a SIP: ACK (if INVITE is used) 



7. H.248 : MOD.req 

[Context ID = CI , Termination ID = T1] 



8. H.248 : MOD.resp 

[Context ID = C1, Termination ID = T1] 



9. SIP: UPDATE/INVITE [SDP, a=sendrecv/recvonly] 



10.S!P:200OK[SDP] 



10.aS!P: ACK (if INVITE is used) 



Figure 51 Session hold from CS networit 



9.3 Mn Signalling procedures 



This clause describes of logical signalling procedures (i.e. message identifiers are not part of the protocol) between the 
MGCF and IM-MGW. The procedures within this clause are intended to be implemented using the standard H.248 
procedure as defined in] ITU recommendation H.248. 1 [2] with appropriate parameter combinations. 

9.3.1 Procedures related to terminations towards the IIVI CN Subsystem 

A mapping of the procedures defined here to H.248 procedures and parameters is provided in 3GPP TS 29.332 [15]. 
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9.3.1 .1 Reserve IMS connection point 

This procedure is used to reserve local connection addresses and local resources. 

Table 25: Procedures toward the IM Subsystem: Reserve IMS connection point 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Reserve IMS 
Connection Point 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


IIVIS Termination 
Request 


M 


This information element requests a new 
IMS termination for the bearer to be 
established. 


Local IIVIS Resources/ 


M 


This information element indicates the 
resource{s) (i.e. codecs) for which the IM- 
MGW shall be prepared to receive user 
data, 


ReserveValue 





This information element indicates if multiple 
local IMS resources are to be reserved. 


Local Connection 
Addresses Request 


M 


This information element requests an IP 
address and port number on the IM-MGW 
that the remote end can send user plane 
data to. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


Reserve IIVIS 

Connection Point 

Ack 


IIVI-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 


Local IMS Resources 


M 


This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from the IMS. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address and port on the IM-MGW that shall 
receive user plane data from IMS. 



9.3.1.2 Configure IIVIS resources 

This procedure is used to select multimedia-processing resources for a Mb interface connection. 



Table 26: Procedures toward the IM Subsystem: Select Local, 
Select Remote IMS Processing Resource 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Configure IMS 
Resources 


MGCF 


Context 


M 


This information element indicates the 
existing context. 


IMS Termination 


M 


This information element indicates the 
existing bearer termination. 


Local IMS Resources 





This information element indicates the 
resources (i.e. codec) that the IM-MGW may 
use on the reception of user plane data. 


Remote IMS 
Resources 


M 


This information element indicates the 
resources (i.e. codec) that the IM-MGW may 
send user plane data to. 


Local Connection 
Addresses 





This information element indicates the IP 
address and port on the IM-MGW that the 
IMS user can send user plane data to. 
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Remote Connection 
Addresses 


M 


This information element indicates the IP 
address and port that the IM-MGW can send 
user plane data to. 






Reserve Value 





This information element indicates if multiple 
IMS resources are to be reserved. 


Configure IMS 

Resources 

Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 


Local IMS Resource 





This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from the far end. 


Remote IMS 
Resource 


M 


This information element indicates the 
resource (i.e. codec) that the IM-MGW shall 
use to send user data to. 


Local Connection 
Address 





This information element indicates the IP 
address and port on the IM-MGW that the 
remote end can send user plane data to. 


Remote Connection 
Address 


M 


This information element indicates the IP 
address and port that the IM-MGW can send 
user plane data to. 



9.3.1 .3 Reserve IMS Connection point and configure remote resources 

This procedure is used to reserve multimedia-processing resources for an Mb interface connection. 
Table 27: Procedures toward the IM Subsystem: reserve local, reserve remote IMS connection point 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Reserve IMS 

Connection Point 

and Configure 

Remote 

Resources 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


IMS Termination/IMS 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a 
new IMS termination for the bearer to be 
established. 


Local IMS Resources 


M 


This information element indicates the 
resource{s) (i.e. codecs) for which the IM- 
MGW shall be prepared to receive user 
data, 


Remote IMS 
Resources 


M 


This information element Indicates the 
resources (i.e. codec) that the IM-MGW 
shall use to send user data in the IMS. 


Reserve Value 





This information element indicates if multiple 
IMS resources are to be reserved. 


Local Connection 
Address request 


M 


This information element requests an IP 
address and a port number on the IM-MGW 
that the remote end can send user plane 
data to. 


Remote Connection 
Addresses 


M 


This information element indicates the IP 
address and ports at an IMS user that the 
IM-MGW can send user plane data to. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


Reserve IMS 

Connection Point 

and Configure 

Remote 
Resources Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


IMS Termination 


M 


This information element indicates the IMS 
termination where the command was 
executed. 
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Local IMS Resources 


M 


This information element indicates the 
resources that the IM-MGW has reserved to 
receive the user plane data from IMS. 


Remote IMS 
Resources 


M 


This information element indicates the 
resource (i.e. codec) that the IM-MGW shall 
use to send user data. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address on the IM-MGW that shall receive 
user plane data from the IMS. 



9.3.1.4 



Release IMS termination 



This procedure is used by the MGCF to release a termination towards the IMS and free all related resources. 

Table 28: Release IMS termination 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release IMS 
Termination 


MGCF 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination to be released. 


Release IMS 
Termination Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



9.3.1.5 



Detect IMS RTP Tel event 



This procedure is used by the MGCF to request from the MGW the detection of telephony events signalled within RTP 
according to RFC 2833 [34] and the notification of received telephony events. This procedure is the same as that is 
defined in the subclause "Detect DTMF" in 3GPP TS 23.205 [27]. 

Table 29: VOID 



9.3.1.6 



Notify IMS RTP Tel event 



This procedure is used by the MGW to notify the MGCF about the detection of telephony events signalled within RTP 
according to RFC 2833 [34]. This procedure is the same as that defined in the subclause "Report DTMF' in 
3GPPTS 23.205 [27]. 

Table 30: VOID 
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9.3.1.7 Void 

9.3.1 .8 Send IMS RTP Tel event 

This procedure is used by the MGCF to request from the MGW to signal a telephone event within RTP according to 
RFC 2833 [34]. This procedure is the same as that defined in the subclause "Send DTMF" in 3GPP TS 23.205 [27]. 

9.3.1 .9 Stop IMS RTP Tel event 

This procedure is used by the MGW to request from the MGW to stop signalling a telephone event within RTP 
according to RFC 2833 [34]. This procedure is the same as that defined in the subclause "Stop DTMF' in 
3GPPTS 23.205 [27]. 

9.3.1 .10 IMS Bearer Released 

This procedure is used by the IM-MGW to indicate towards the MGCF that an error occured on an IMS termination 
which requires the release of the termination. This procedure is the same as that defined in the subclause 'Bearer 
Released' in 3GPP TS 23.205 [27]. 

9.3.1.11 End IMS RTP Tel event 

This procedure is used by the MGCF to indicate to the IM-MGW to stop detection of telephony events signalled within 
RTP according to IETF RFC 2833 [34]. This procedure is the same as that is defined in the subclause "Stop Detect 
DTMF" in 3GPP TS 23.205 [27]. 

9.3.1.12 IMS Send Tone 

This procedure is used by the MGCF to order the IM-MGW to generate a tone at termination towards IMS. This 
procedure is the same as that defined in the subclause 'Send Tone' in 3GPP TS 23.205 [27]. 

9.3.1.13 IMS Stop Tone 

This procedure is used by the the MGCF to order the IM-MGW to stop generating a tone at a termination towards IMS 
This procedure is the same as that defined in the subclause 'Stop Tone' in 3GPP TS 23.205 [27]. 

9.3.1.14 IMS Tone Completed 

This procedure is used by the IM-MGW to indicate to the MGCF that a tone has finished being generated at a 
termination. This procedure is the same as that defined in the subclause 'Tone Completed' in 3GPP TS 23.205 [27]. 



9.3.2 Procedures related to a termination towards an ISUP network 

A mapping of the procedures defined here to H.248 procedures and parameters is provided in 3GPP TS 29.332 [15]. 

9.3.2.1 Reserve TDM circuit 

This procedure is used by the MGCF to reserve a TDM circuit in the IM-MGW towards the preceding/succeeding CS 
network element. 
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Table 31 : Reserve TDM circuit procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Reserve TDM 
Circuit 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
physical bearer termination for the TDM 
circuit. 


Bearer Service 
Characteristics 


M 


This information element indicates the 
bearer service requested by the user. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer 


Reserve Circuit 
Ack 


IIVI-MGW 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the 
bearer termination where the command was 
executed. 



9.3.2.2 Change TDM through-connection 

This procedure is used by the MGCF to modify the through-connection (forward, backward, both-way, inactive) of a 
TDM termination at the IM-MGW towards the PSTN. 

This procedure is the same as Change Through Connection in TS 23.205 [27]. 

9.3.2.3 Activate TDM voice-processing function 

This procedure is used by the MGCF to activate or de-activate a voice processing function of a TDM termination at the 
IM-MGW towards the PSTN. This voice processing function may include a cancellation for electronic echoes. 

This procedure is the same as Activate Voice Processing Function in 3GPP TS 23.205 [27]. 

9.3.2.4 Send TDM tone 

This procedure is used by the MGCF to order the IM-MGW to generate a tone at a TDM termination towards the 
PSTN. 

This procedure is the same as Send Tone in 3GPP TS 23.205 [27]. 

9.3.2.5 Stop TDM tone 

This procedure is used by the MGCF to order the IM-MGW to stop generating a tone at a TDM termination towards the 
PSTN. 

This procedure is the same as Stop tone in 3GPP TS 23.205 [27]. 

9.3.2.6 Play TDM announcement 

This procedure is used by the MGCF to order the IM-MGW to generate an announcement at a TDM termination 
towards the PSTN. The MGCF may request a notification that the announcement is completed. This procedure is the 
same as Play Announcement in 3GPP TS 23.205 [27]. This procedure is optional. 



9.3.2.7 



TDM announcement completed 



This procedure is used by the IM-MGW to notify the MGCF that an announcement at a TDM termination towards the 
PSTN is completed. This procedure is the same as Announcement Completed in 3GPP TS 23.205 [27]. This procedure 
is optional. 
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9.3.2.8 



Stop TDM announcement 



This procedure is the same as Stop Announcement 3GPP TS 23.205 [27]. This procedure is used by the MGCF to order 
the IM-MGW to stop generating an announcement at a TDM termination towards the PSTN. This procedure is optional. 



9.3.2.9 



Continuity check 



This procedure is used by the MGCF to order the IM-MGW to generate a continuity check tone at a TDM termination 
towards the PSTN and to inform the MGCF about the result of the continuity check as soon as the continuity check tone 
is received or a time-out occurs. This procedure is optional. 



Table 32: Continuity checit procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity checl< 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDM Termination 


M 


This information element indicates the 
existing bearer termination 






Request for continuity 
tone sending 


M 


This information request the IM-MGW to 
apply the continuity check procedure on the 
indicated TDM termination 






Request for continuity 
cliecl< tone detection 


M 


This information request the IM-MGW to 
inform e continuity check procedure on the 
indicated TDM termination 


Continuity Checl< 
Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



9.3.2.10 Continuity check verify 

This procedure is used by the IM-MGW to indicate towards the MGCF that the continuity check at a TDM termination 
towards the PSTN has been completed and to return the result of the check: success or failure. This procedure is 
optional. 

Table 33: Continuity checit verify procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity check 
Verify 


IM-MGW 


Context/t 


M 


This information element indicates the 
context where the command was executed. 






TDM Termination 


M 


This information element indicates the TDM 
termination involved in the procedure 






Outcome of the 
continuity check 


M 


This information element indicates the 
outcome of the continuity check 
(successful/unsuccessful) 


Continuity Check 
Verify Ack 


MGCF 


Context 


M 


This information element indicates the 
context where the command was executed. 



9.3.2.1 1 Continuity check response 

This procedure is used by the MGCF to order the IM-MGW to loop back an incoming continuity check tone at a TDM 
termination towards the PSTN. This procedure is optional. 
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Table 34: Continuity cliecl< response procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity checl< 
response 


MGCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDIVI Termination 


M 


This information element indicates the 
existing bearer termination 






Request for loop back 
of the continuity tone 


M 


This information request the IM-MGW to 
loop back the continuity check tone on the 
indicated TDM termination 


Continuity Cliecl< 
Response Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



9.3.2.12 



Release TDM termination 



This procedure is used by the MGCF to release a TDM termination at the IM-MGW towards the PSTN and free all 
related resources. 

Table 35: Release TDIVI termination procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release TDM 
Termination 


MGCF 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination to be released. 


Release TDM 
Termination Ack 


IM-MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



9.3.2.13 



Termination Out-of-Service 



This procedure is used by the IM-MGW to indicate towards the MGCF that one or several physical termination(s) will 
go out of service. This procedure is the same as Termination Out-of-Service in 3GPP TS 23.205 [27]. 



9.3.2.14 



Bearer Released 



This procedure is used by the IM-MGW to indicate towards the MGCF that an error occured on a physical termination 
which requires the release of the termination. This procedure is the same as Bearer Released in 3GPP TS 23.205 [27]. 

9.3.2.1 5 TDM tone completed 

This procedure is used by the IM-MGW to MGCF to indicate that a tone has finished being generated at a TDM 
termination. 

This procedure is the same as Tone Completed in 3GPP TS 23.205 [27]. 



9.3.3 Procedures related to a termination towards a BICC network 

The call related procedures detailed in table 36 shall be supported. Those procedures are defined in 3GPP TS 29.332 
[15]. 
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Table 36: Required procedures defined in 3GPP TS 29.332 procedures 



Procedure defined in 3GPP TS 29.232 


Remarks 


Establish Bearer 




Prepare Bearer 




Change Through-Connection 




Release Bearer 




Release Termination 




Bearer Established 




Bearer Released 




Send Tone 




Stop Tone 




Tone completed 




Play Announcement 


Optional 


Stop Announcement 


Optional 


Announcement Completed 


Optional 


Confirm Char 


Optional 


Modify Bearer Characteristics 


Optional 


Reserve Char 


Optional 


Bearer IVIodified 


Optional 


Activate Voice Processing Function 


Optional 


Tunnel Information Down 


Conditional: For IP Transport at 
BICC termination 


Tunnel Information Up 


Conditional: For IP Transport at 
BICC termination 


Termination Out-of-Service 





9.3.4 Non-call related procedures 

The procedures from 3GPP TS 23.205 [27] detailed in table 37 shall be applied for the IM-MGW handling component of the Mn 
interface. 

Table 37: Non-call related procedures 



Procedure defined in 
3GPPTS 29.332 [15] 


Corresponding Procedure defined 
in 3GPP TS 23.205 [27]] 


Remarl(s 


IM-MGW Out of service 


MGW Out of Service 




IM-MGW Communication Up 


MGW Communication Up 




IM-MGW Restoration 


MGW Restoration 




IM-MGW Register 


MGW Register 




IM-MGW Re-register 


MGW Re-register 




MGCF Ordered Re-register 


(G)MSC Server Ordered Re-register 




MGCF Restoration 


(G)MSC Server Restoration 




MGCF Out of Service 


(G)MSC Server Out of Service 




Termination Out-of-Service 


Termination Out-of-Service 


The 'Termination Out-of-Service 
procedure' is used as call-related 
H248 command as well 


Termination Restoration 


Termination Restoration 




Audit Value 


Audit Value 




Audit Capability 


Audit Capability 




Command Rejected 


Command Rejected 


The 'Command Rejected' procedure 
may be used in response both to 
call-related and non-call-related 
H.248 Commands. 


IM-MGW Capability Change 


Capability Update 




IM-MGW Resource Congestion 
Handling - Activate 


MGW Resource Congestion 
Handling - Activate 




IM-MGW Resource Congestion 
Handling - Indication 


MGW Resource Congestion 
Handling - Indication 
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Annex A (informative): 

Summary of differences items between 3GPP TS 29.163 

and ITU-T Q.1 91 2.5 



The present document specifies the principles of interworking between the 3GPP IM CN subsystem and BICC/ISUP 
based legacy CS networks, in order to support IMS basic voice calls. A specification exists in the ITU-T that covers 
similar work: Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control Protocol or 
ISDN User Part. (ITU-T Q. 1912.5 [49]) in order to support services that can be commonly supported by BICC or ISUP 
and SIP based network domains. Three profiles are described in the ITU-T specification: A, B, and C. Profile B and C 
are out of the scope of the present specification. 

3GPP intends to strive for alignment with ITU-T Q. 1912.5 [49], however some differences exist. This annex contains a 
list of these differences. Future revisions of this document will seek to incorporate text to address these differences. 

This Annex is intended as an informative tool for the designer community and operators to understand the main 
differences between 3GPP and ITU recommendations for the SIP-BICC/ISUP interworking. 

The list of differences between TS 29.163 and ITU-T Q. 1912.5 [49] is referred to profile A of the latter. 



A.I List of differences 



1. TablelO (TS 29.163) vs. Table 22/Q.1912.5 (ITU-T Q.1912.5 [49]) 

Extra entry comprising the case when SIP procedures result in release after answer. 

2. Tablell (TS 29.163) vs. Table 25/Q.1912.5 (ITU-T Q.1912.5 [49]) 

Hostportion was removed in 3GPP table. 

3. Table 12 (TS 29.163) vs. Table 27/Q.1912.5 (ITU-T Q.1912.5 [49]) 

Use of Tel URL instead of Addr-spec. 

4. Table 13 (TS 29.163) vs. Table 28/Q.1912.5 (ITU-T Q.1912.5 [49]) 

Address signal is not mapped. 

5. Table 14 (TS 29.163) vs. Table 29/Q.1912.5 (ITU-T Q.1912.5 [49]) 

Tel URL used instead of Addr-spec. 

6. Satellite indicator 

It is set to '01 one satellite circuit in the connection'. While in ITU-T Q.1912.5 [49] is set to '00 No satellite circuit in 
the connection' 



7. The mapping of the Reason Header and the Location Field mapping is missing in the 3GPP specification, whereas in 
ITU is specified. 

The reason for this is that the Reason Header was included in IMS only as optional. As the reason header is optional, 
it can be proprietary interworked and in that case ITU-T mapping recommendation can be used. 



8. COLP/COLR Service interworked is included in 29.163, and leftFFS in ITU-T Q.1912.5 [49] 
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Annex B (normative): 

Codec Negotiation between a BICC CS network and the IM 

CN subsystem 

B.1 Introduction 

This annex describes optional procedures for interworking of codec negotiation between a BICC CS network and the 
IM CN subsystem. 

B.2 Control plane interworking 

The following optional procedures apply in addition to the procedures of clause 7.3 when both the BICC CS network 
and the IM CN subsystem support codec negotiation. All five variations of the bearer set-up procedures defined in 
clauses 7.4 and 7.5 of ITU-T Q. 1902.4 [30] are supported. The codec negotiation procedures are also independent of the 
procedures for interworking between continuity procedures and SDP preconditions. 

B.2.1 Incoming call interworking from SIP to BICC at l-MGCF 
B. 2.1.1 Sending of lAM 

When the I-MGCF receives an INVITE with SDP offer, the I-MGCF shall follow the procedures of clause B.2.5 to 
convert the list of codecs in the SDP offer into a Supported Codec List for transmission in the outgoing lAM, according 
to clause 8.3.1 of ITU-T Q. 1902.4 [30], and deleting those codecs not supported at the IM-MGW. When generating the 
Supported Codec List, the I-MGCF should add to the SDP offer all codec configurations for which it can provide 
transcoding. The I-MGCF shall allocate any IM-MGW resources as necessary to support the chosen bearer set-up 
procedures towards the BICC CS network. 

When the I-MGCF receives an INVITE without SDP offer, the I-MGCF shall continue call establishment without 
interworking of codec negotiation procedures. The mid-call interworking procedures of clause B.2. 3 and clause B.2. 4 
may still apply. 

B.2.1 .2 Sending of SDP answer 

The I-MGCF shall suspend the SDP answer procedure until it receives backward codec information from the BICC 
serving node terminating codec negotiation. When the I-MGCF receives the backward codec information, it shall select 
a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP offer, format 
an SDP answer based on this selected codec, send the SDP answer to the offerer in the appropriate SIP message (e.g., a 
reliable 18x response), and complete bearer establishment procedures. To avoid allocating a transcoder at the IM- 
MGW, the I-MGCF should preferably select a codec for the IM CN subsystem by converting the Selected Codec from 
the BICC CS network into an SDP answer according to the procedures of clause B.2.5, if allowed by the SDP 
offer/answer rules. Otherwise the I-MGCF should select the highest priority codec from the codecs in the received SDP 
offer supported by the IM-MGW for insertion in the SDP answer. Note that the I-MGCF stores the Available Codec 
List and does not send it to the offerer in the SDP answer. Codec negotiation is complete so it is not necessary for the 
offerer to begin a second phase offer/answer exchange using the PRACK request. 

B.2.2 Outgoing call interworking from BICC to SIP at 0-MGCF 



B.2.2.1 Sending of INVITE 



When the O-MGCF receives an lAM, the 0-MGCF shall follow the procedures of clause B.2.5 to convert the 
Supported Codec List from the lAM into an SDP offer for transmission in the outgoing INVITE request, according to 
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RFC 3264, deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the O-MGCF should 
include all codec configurations for which it can provide transcoding in addition to those converted from the Supported 
Codec List. The O-MGCF shall include at least one AMR codec configuration in the SDP offer. The O-MGCF shall 
allocate any IM-MGW resources as necessary to support the inclusion of session address information in the SDP offer 
towards the IM CN subsystem. 

B.2.2.2 Responding to serving node initiating codec negotiation 

The O-MGCF shall suspend the incoming bearer set-up procedure while waiting for receipt of the SDP answer from the 
IM CN subsystem. When the O-MGCF receives the SDP answer while suspending the incoming bearer set-up 
procedure, it shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs 
in the SDP answer, construct the Available Codec List for the BICC CS network from the list of codecs received in the 
Supported Codec List by removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS 
network from the codecs in the Available Codec List, initiate the second SDP offer/answer exchange with the IM CN 
subsystem using the codec selected for the IM CN subsystem, if necessary, and resume the incoming bearer set-up 
procedure in the BICC CS network. The O-MGCF should select codecs for the bearer interfaces to the BICC CS 
network and IM CN subsystem in such a way as to avoid transcoding at the IM-MGW and minimize speech 
degradation, if possible, according to clause B.2.5. Otherwise the O-MGCF should choose the highest priority codec 
from the Available Codec List as the Selected Codec for the BICC CS network, and the highest priority codec from the 
codecs in the SDP answer as the codec for the IM CN subsystem. If the SDP answer only included a single voice codec, 
then there is no need for a second SDP offer/answer exchange, and the codec selected for the IM CN subsystem is the 
codec in the SDP answer. 

Certain BICC timers or events can force completion of the incoming bearer set-up procedure before the O-MGCF 
receives the SDP answer from the IM CN subsystem. In this case, the O-MGCF shall perform the terminating codec 
negotiation procedure according to clause 8.3.3 of ITU-T Q. 1902.4 [30], including all supported codecs in the Available 
Codec List, and shall resume the incoming bearer set-up procedure without waiting any longer for the SDP answer. 

When an SDP answer arrives from the IM CN subsystem in response to the SDP offer in an INVITE request after the 
BICC incoming bearer set-up procedure has started, the O-MGCF shall select a codec configuration for use on the 
bearer interface to the IM CN subsystem from the codecs in the SDP answer, choose a new Selected Codec for the 
BICC CS network from the codecs in the Available Codec List constructed during incoming bearer set-up, and initiate 
the second SDP offer/answer exchange with the IM CN subsystem using the codec selected for the IM CN subsystem, if 
necessary. The O-MGCF should select codecs for the bearer interfaces to the BICC CS network and IM CN subsystem 
in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according to 
clause B.2.5. Otherwise the O-MGCF should select the highest priority codecs from the available options for the two 
bearer interfaces. If the SDP answer only included a single voice codec, then there is no need for a second SDP 
offer/answer exchange, and the codec selected for the IM CN subsystem is the codec in the SDP answer. When the call 
in the BICC CS network enters a state capable of supporting codec modification, if the new Selected Codec is different 
from the Selected Codec chosen during the incoming bearer set-up procedure for the BICC CS network, the O-MGCF 
should initiate the codec modification procedure towards the BICC CS network using the new Selected Codec, 
according to clause 10.4.1 of ITU-T Q. 1902.4 [30]. 

B.2.3 Mid-call interworking from SIP to BICC at l-MGCF or O- 
MGCF 



B.2.3. 1 Receipt of SDP offer 



When the MGCF receives a SIP message (e.g. UPDATE request or re-INVITE request) with an SDP offer that is not 
associated with incoming call bearer establishment or preconditions, if the call is in a state capable of supporting BICC 
codec negotiation, the MGCF shall follow the procedures of clause B.2.5 to convert the list of codecs in the SDP offer 
into a Supported Codec List, delete those codecs in the Supported Codec List not supported at the IM-MGW, and 
initiate the mid-call codec negotiation procedure according to clause 10.4.4 of ITU-T Q. 1902.4 [30], by sending an 
APM with the Supported Codec List and an Action indicator set to 'mid-call codec negotiation'. When generating the 
Supported Codec List, the MGCF should add to the SDP offer all codec configurations for which it can provide 
transcoding. 

When the MGCF receives a SIP message with an SDP offer that is not associated with incoming call bearer 
establishment or preconditions, if the call is not in a state capable of supporting BICC codec negotiation, the MGCF 
shall respond to the SDP offer with existing procedures for the IM CN subsystem. When the call is in a state capable of 
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supporting BICC codec negotiation, the MGCF may send a re-INVITE request without SDP towards the IM CN 
subsystem, soliciting a response with an SDP offer, thereby restarting the codec negotiation interworking procedure. 

B. 2.3.2 Generating SDP answer 

After initiating a BICC codec negotiation procedure towards the BICC CS network in response to receipt of a SIP 
message with an SDP offer from the IM CN subsystem, the MGCF shall suspend the SDP answer procedure until it 
receives codec information from the succeeding BICC serving node. If the succeeding serving node returns a successful 
response, the MGCF shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the 
codecs in the SDP offer, format an SDP answer based on this selected codec, send the SDP answer to the offerer in the 
appropriate SIP message (e.g. 200 OK (UPDATE) or 200 OK (INVITE)), send an APM to the succeeding serving node 
with an Action indicator set to 'successful codec modification', and complete bearer establishment procedures. To avoid 
allocating a transcoder at the IM-MGW, the MGCF should preferably select a codec for the IM CN subsystem by 
converting the Selected Codec from the BICC CS network into an SDP answer according to the procedures of clause 
B.2.5, if allowed by the SDP offer/answer rules. Otherwise the MGCF should select the highest priority codec from the 
codecs in the received SDP offer supported by the IM-MGW for insertion in the SDP answer. Note that the MGCF 
stores the Available Codec List and does not send it to the offerer in the SDP answer. 

If the succeeding serving node returns an Action indicator set to 'mid-call codec negotiation failure', the MGCF either 
should send a 488 response to the SDP offerer indicating rejection of the initial SDP offer, or should select the highest 
priority codec from the codecs in the received SDP offer supported by the IM-MGW, format an SDP answer based on 
this selected codec, and send the SDP answer to the offerer in the appropriate SIP message. If the MGCF sends a 488 
response to the SDP offerer, it should continue the call with the bearer configuration in place before initiating this codec 
negotiation procedure. 

B.2.4 Mid-call interworking from BICC to SIP at l-MGCF or O- 
MGCF 

B.2.4. 1 Receipt of mid-call codec negotiation request 

When the MGCF receives an APM with an Action indicator set to 'mid-call codec negotiation', the MGCF shall follow 
the procedures of clause B.2.5 to convert the Supported Codec List from the APM into an SDP offer for transmission in 
an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, according to RFC 3264 [36], 
deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the MGCF should include all 
codec configurations for which it can provide transcoding in addition to those converted from the Supported Codec List. 
The MGCF shall include at least one AMR codec configuration in the SDP offer. 

B.2.4. 2 Responding to serving node initiating mid-call codec negotiation 

The MGCF shall delay responding to the mid-call codec negotiation from the BICC CS network until it receives a 
response to the SDP offer from the IM CN subsystem. If the MGCF receives an SDP answer, it shall construct the 
Available Codec List for the BICC CS network from the list of codecs received in the Supported Codec List by 
removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS network from the codecs 
in the Available Codec List, and complete the mid-call codec negotiation procedure towards the preceding serving node 
according to clause 10.4.5 of ITU-T Q. 1902.4 [30]. The MGCF should choose the Selected Codec for the BICC CS 
network in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according 
to clause B.2.5. Otherwise the MGCF should choose the highest priority codec from the Available Codec List for the 
Selected Codec for the BICC CS network. If the MGCF receives an APM from the preceding serving node with an 
Action indicator set to 'codec modification failure', then the MGCF may initiate a new SDP offer/answer exchange 
towards the IM CN subsystem in an attempt to recreate the bearer configuration in place before this codec negotiation 
procedure began. 

If the MGCF receives a 488 response or other failure response (e.g. 3xx-6xx) to the SDP offer, either it should reject the 
mid-call codec negotiation from the BICC CS network by sending an APM with an Action indicator set to 'mid-call 
codec negotiation failure' towards the preceding serving node, or it should continue as if it received an SDP answer with 
no change in codec selected for the IM CN subsystem. If the MGCF sends an APM with an Action indicator set to 'mid- 
call codec negotiation failure', it should continue the call with the bearer configuration in place before initiating this 
codec negotiation procedure. 
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B.2.4.3 Receipt of codec modification request 

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to 'modify codec' with no 
change in the selected codec, it shall act as a serving node terminating codec modification, according to clause 10.4.2 of 
ITU-T Q. 1902.4 [30], without interworking the procedure with the IM CN subsystem. 

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to 'modify codec' and the 
new selected codec in the message is different from the Selected Codec at the IM-MGW bearer interface to the BICC 
CS network, the MGCF either may act as a serving node terminating codec modification, according to clause 10.4.2 of 
ITU-T Q. 1902.4 [30], without interworking the procedure with the IM CN subsystem, or may follow the procedures of 
clause B.2.5 to convert the new Available Codec List (with new priority order) from the APM into an SDP offer for 
transmission in an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, according to RFC 
3264 [36], deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the MGCF should 
include all codec configurations for which it can provide transcoding in addition to those converted from the new 
Available Codec List. The MGCF shall include at least one AMR codec configuration in the SDP offer. 

If the MGCF sends a SIP message with an SDP offer towards the IM CN subsystem in response to receipt of a BICC 
codec modification request, then it shall delay responding to the BICC codec modification request until it receives a 
response to the SDP offer from the IM CN subsystem. When the MGCF receives either an SDP answer or a rejection of 
the SDP offer within the appropriate SIP message (e.g. 200 OK (INVITE)) from the IM CN subsystem, it shall decide 
whether to accept or reject the BICC codec modification procedure and complete the procedure for a BICC serving 
node terminating codec modification, according to clause 10.4.2 of ITU-T Q. 1902.4 [30]. 

If the MGCF sends an APM with an Action indicator set to 'codec modification failure' in response to receipt of a codec 
modification request, the preceding BICC serving node may retry the request with a mid-call codec negotiation using an 
APM including an Action indicator set to 'mid-call negotiation' and a Supported Codec List with a new priority order 
encouraging selection of a new codec. 

B.2.5 Codec parameter translation between BICC CS network 
and the IM CN subsystem 

The IM CN subsystem uses the Session Description Protocol (SDP, defined in RFC 2327 [56]) to select and potentially 
re-negotiate the codec type and configuration and associated bearer format attributes to be used in the user plane. RFC 
3550 [51] defines the Real Time Protocol (RTP) for framing of all codecs in the user plane, RFC 3551 [52] and RFC 
3555 [53] define the framing details for many of the ITU-T codecs, and RFC 3267 [23] defines framing details for the 
AMR family of codecs. This clause will focus only on codec-specific SDP parameters not already constrained by clause 
5.1.1 of TS 26.236 [32]. The signalling plane of the IM CN subsystem uses SDP offer/answer procedures defined in 
RFC 3264 [36] to select the desired codec type and configuration for the user plane from a prioritized list of codec types 
and configurations and to re-negotiate the user plane attributes as necessary. 

The bearer independent CS network uses the Single Codec and Codec List information elements of the Application 
Transport Mechanism (APM) defined in ITU-T Q.765.5 [35] to negotiate (offer and select) and potentially re-negotiate 
the codec type and configuration and associated bearer format attributes to be used in the user plane. TS 29.414 [25] 
and TS 25.415 [26] define the luFP framing protocol for all codecs in the user plane for both ATM and IP transport, and 
TS 26.102 [50] provides the framing details for AMR and PCM family codecs. The Codec List information element of 
the APM comprises multiple instances of the Single Codec information element in priority order, as shown in Figure 13 
of ITU-T Q.765.5 [35]. Figure 14 of ITU-T Q.765.5 [35] defines the Single Codec information element. Clause 11.1.7.2 
of ITU-T Q.765.5 [35] defines the encoding of the Single Codec information element for the ITU-T codecs. TS 26.103 
[57] defines the encoding of the Single Codec information element for the 3GPP codecs, and Table 7.11.3.1.3-2 of TS 
28.062 [58] defines the preferred configurations of the narrowband AMR codecs (Config-NB-Code) for interoperation 
with TFO. The signalling plane of the bearer independent CS network uses the APM to negotiate the desired codec type 
and configuration for the user plane from the prioritized list of codec types and to re-negotiate the user plane attributes 
as necessary. 

The following subclauses define the translations between the SDP payload format parameters of the IM CN subsystem 
and the corresponding subfields of the Single Codec information element of the bearer independent CS network for 
certain 3GPP and ITU-T codecs. Following these translation rules will in many cases allow the IM-MGW to perform 
interworking between the framing protocols on the bearer interfaces to the BICC CS network and the IM CN subsystem 
without transcoding. Implementations may signal other codec types not listed herein or other codec configurations of 
codec types listed herein. Implementations may also choose to perform transcoding between codec configurations 
signalled separately for the bearer interfaces to the networks, if necessary, but voice quality may suffer. 
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B.2.5.1 Codec parameters for 3GPP AMR-NB codecs 

Table B.l shows the correspondence between the codec format parameters in the Single Codec information element (TS 
26.103 [57]) and the SDP for the 3GPP narrowband AMR codecs (RFC 3267 [23]). 

Table B.1 : Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-NB codecs 



Single Codec information element 


SDP payload format parameters 


Codec 
IDentification 


ACS, SCS, OM, 
MACS 


Payload 
Type number 


Encoding 
name 


Other Parameters 

(N0TE1)(N0TE2) 


FR AMR or 
OHR AMR or 
HR AMR 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding to 
ACS (NOTE 3) 


FR AMR or 
OHR AMR or 
HR_AMR 


(0M=1 or OM not 
present) and 
(Supported Codec List 
or Available Codec 
List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 3) 


UMTS_AMR 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding to 
ACS 


UMTS_AMR 


(0M=1 or OM not 
present) and 
(Supported Codec List 
or Available Codec 
List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 4) 


UMTS_AMR_2 


OM=0 or 

Selected Codec Type 


dynamic 


AMR 


mode-set=values corresponding to 
ACS (NOTE 5) 


UMTS_AMR_2 


(0M=1 or OM not 
present) and 
(Supported Codec List 
or Available Codec 
List) 


dynamic 


AMR 


mode-set=select from values 
corresponding to ACS, SCS and 
MACS (NOTE 3) (NOTE 5) 


NOTE 1 : Table 1 of RFC 3267 [23] provides the correspondence between codec rates and AMR modes for use when 

generating the 'mode-set' parameter. When all modes are selected for use, the 'mode-set' parameter shall not 
be included in SDP. 

NOTE 2: SDP payload format configurations in this table with only one value in the 'mode-set' parameter shall not 
include the 'mode-change-period' and 'mode-change-neighbor' parameters. 

NOTE 3: Payload types for FR_AMR, OHR_AMR and HR_AMR with more than one value in the 'mode-set' parameter 
shall include the 'mode-change-period=2' parameter and should include the 'mode-change-neighbor=1' 
parameter. 

NOTE 4: RFC 3267 [23] does not currently provide a mechanism to signal the SCS, MACS or OM parameters in SDP, 
nor does it distinguish between the different AMR-NB codec types. Each AMR-NB codec type in the 
Supported Codec List or the Available Codec List with 0M=1 should be translated into a list of SDP payload 
formats in priority order, where each includes a 'mode-set' parameter with a unique value derived from the 
ACS, SCS and MACS. Each 'mode-set' should correspond to a codec configuration that is compatible with 
the given codec type according to the compatibility rules defined in clauses 1 1 and 12 of TS 28.062 [58]. 

NOTE 5: Payload types for UMTS_AMR_2 should include the 'mode-change-period=2' and 'mode-change-neighbor=1 ' 
parameters, normally used for signalling GSM AMR codecs, to assure end-to-end interoperability with OoBTC 
and TFO. Its actual capabilities would otherwise be signalled without these two parameters. 



Definitions: 

Supported Codec List: contains the offered Codec Types and Configuration-possibilities of the node initiating codec 
negotiation in BICC (see also TS 23.153). The Supported Codec List is sent from the initiating node forward to the 
terminating node. The Supported Codec List corresponds to an SDP offer during codec negotiation.. 

Available Codec List: contains the offered Codec Types and Configuration-possibilities of the contiguous portion of 
the connection between initiating and terminating BICC nodes, including all intermediate nodes through the BICC 
network(s). The Available Codec List is sent from the BICC node terminating codec negotiation backward to the 
initiating node. The Available Codec List corresponds to information sometimes available in a first-round SDP answer. 
The Available Codec List might not represent an end-to-end view of the available Codec Types and Configuration- 
possibilities when traversing both BICC and SIP networks. 

Selected Codec Type: is determined by the node terminating codec negotiation. It specifies exactly the Codec Type and 
one unique Codec Configuration for the call. The Selected Codec Type corresponds to the final SDP answer. 
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When translating from a Single Codec information element to the equivalent SDP payload format parameters, where 
either OM=0 (in the Supported or Available Codec List) or the information element is the Selected Codec Type, the 
SDP shall include a single payload type and any associated parameters from the corresponding row in Table B.l. When 
translating from a Single Codec information element to the equivalent SDP payload format parameters, where OM=l in 
the Supported or Available Codec List, the SDP shall only include payload formats corresponding to Codec 
Configurations compatible with the offered ACS, SCS and MACS, according to Table B.L Since the number of 
compatible payload formats can be large, implementations should select a reasonable subset of the higher-priority 
payload formats for inclusion in the SDP. When translating a list of Single Codec information elements into SDP, 
duplicate payload types (matching on all parameters) shall be removed. 

The following guidelines shall apply when translating from an SDP payload format specification to a Single Codec 
information element: 

If there is no 'mode-set' parameter for a payload format in the SDP and the SDP is to be translated into a 
Supported or Available Codec List, then the corresponding Single Codec subfields shall be OM=l, MACS=8, all 
SCS modes offered, and ACS modes offered. Alternatively it is sufficient to specify only the Codec Type (see 
below) and omit the other parameters. 

If there is no 'mode-set' parameter for a payload format in an SDP answer that is to be translated into a Selected 
Codec Type, then the corresponding Single Codec subfields shall be derived from the payload type in the SDP 
offer (to which the SDP answer was sent in response). 

If there is a 'mode-set' parameter for a payload format in the SDP, then the corresponding Single Codec subfields 
shall be OM=0 and ACS modes selected according to the value of 'mode-set'. The SCS shall be set identical to 
the ACS and MACS shall be set to the number of modes in the ACS. If this 'mode-set' does not represent a valid 
configuration for the Codec Type (determined by OoBTC procedures), then the payload format shall not be 
translated. 

If a payload format in an SDP offer that is to be translated into a Supported Codec List includes 'mode-change- 
period=2', then the Codec IDentification value for the corresponding Single Codec shall be FR_AMR. 

If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List 
includes 'mode-change-period=2', then the Codec IDentification value for the corresponding Single Codec shall 
be one of FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR_2, if offered in the Supported Codec List. 

If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include 'mode- 
change-period=2', then the Codec IDentification value for the corresponding Single Codec shall be 
UMTS_AMR. 

If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List 
does not include 'mode-change-period=2', then the Codec IDentification value for the corresponding Single 
Codec shall be one of UMTS_AMR_2, FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR, if offered in the 
Supported Codec List. 

B. 2.5.2 Codec parameters for 3GPP AMR-WB codecs 

Table B.2 shows the correspondence between the codec format parameters in the Single Codec information element (TS 
26.103 [57]) and the SDP for the 3GPP wideband AMR codecs (RFC 3267 [23]). 
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Table B.2: Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-WB codecs 



Single Codec information element 


SDP payload format parameters 


Codec IDentification 


Config-WB-Code 


Payload Type 
number 


Encoding name 


Other Parameters 

(N0TE1) 


FR AMR-WB or 
OHR AMR-WB 





dynamic 


AMR-WB 


mode-set=0,1,2 


OFR AMR-WB or 
UMTS AMR-WB 





dynamic 


AMR-WB 


mode-set=0,1,2 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


1 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0,1,2 
mode-set=0,1,2,8 
mode-set=0, 1,2,4 
(NOTE 2) 


OFR AMR-WB or 
UMTS AMR-WB 


2 


dynamic 


AMR-WB 


mode-set=0,1,2,4 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


3 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0, 1,2,4 
mode-set=0, 1,2,8 
mode-set=0,1,2 
(NOTE 2) 


OFR AMR-WB or 
UMTS AMR-WB 


4 


dynamic 


AMR-WB 


mode-set=0,1,2,8 
(NOTE 2) 


OFR AMR-WB or 
UMTS_AMR-WB 


5 


dynamic 
dynamic 
dynamic 


AMR-WB 
AMR-WB 
AMR-WB 


mode-set=0,1,2,8 
mode-set=0, 1,2,4 
mode-set=0,1,2 
(NOTE 2) 


NOTE 1 : Payload types for FR_AMR-WB, OHR_AMR-WB and OFR_AMR-WB sliall include the 'mode-change- 
period=2' parameter and should include the 'mode-change-neighbor=1' parameter. 

NOTE 2: Payload types for UMTS_AMR-WB should include the 'mode-change-period=2' and 'mode-change- 
neighbor=1' parameters, normally used for signalling GSM AMR-WB codecs, to assure end-to-end 
interoperability with OoBTC and TFO. Its actual capabilities would otherwise be signalled without these two 
parameters. 



When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP 
shall include a distinct payload type and any associated parameters for each row in the table that matches the Config- 
WB-Code parameter. For example, OFR_AMR-WB with Config-WB-Code=3 can generate three SDP payload types 
for AMR-WB, each including the "mode-change-period=2" parameter, the 'mode-change-neighbor=r parameter, and 
the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and "0,1,2", respectively. When translating a list of Single 
Codec information elements into SDP, duplicate payload types (matching on all parameters) shall be removed. 

The following guidelines shall apply when translating from one or more SDP payload format specifications to a Single 
Codec information element: 

Payload formats that match except for different values of 'mode-set' shall be represented with the fewest values 
of Config-WB-Code, while retaining the priority represented by the order of the payload formats in the SDP. 
For example, three SDP payload types for AMR-WB, each including the "mode-change-period=2" parameter, 
the 'mode-change-neighbor=r parameter, and the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and 
"0,1,2", respectively, will generate Config-WB-Code=3. 

If there is no 'mode-set' parameter for a payload format in the SDP and the SDP is to be translated into a 
Supported or Available Codec List, then the corresponding Single Codec shall have a Config-WB-Code value of 
I. 

If there is no 'mode-set' parameter for a payload format in an SDP answer that is to be translated into a Selected 
Codec Type, then the corresponding Config-WB-Code value shall be derived from the payload type in the SDP 
offer (to which the SDP answer was sent in response). 

If a payload format in an SDP offer that is to be translated into a Supported Codec List includes 'mode-change- 
period=2', then the Codec IDentification value for the corresponding Single Codec shall be OFR_AMR-WB. 

If a payload format in an SDP answer is to be translated into a Selected Codec Type or Available Codec List, 
then the Codec IDentification value for the corresponding Single Codec shall be one of OFR_AMR-WB, 
FR_ AMR-WB, OHR_AMR-WB or UMTS_AMR-WB, if offered in the Supported Codec List. 
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If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include 'mode- 
change-period=2', then the payload format shall not be translated. 

B.2.5.3 Codec parameters for 3GPP non-AMR codecs 

Table B.3 shows the correspondence between the codec format parameters in the Single Codec information element (TS 
26.103 [57]) and the SDP for the 3GPP non-AMR codecs (RFC 3267 [23], RFC 3551 [52], and RFC 3555 [53]). 

Table B.3: Mapping between Single Codec subfields and SDP parameters for 3GPP non-AMR codecs 



Single Codec information element 


SDP payload format parameters 


Codec IDentification 


Payload Type number 


Encoding name 


Other Parameters 


GSMFR 


3 


GSM 




GSMHR 


N/A 


N/A 




GSM EFR (NOTE 1) 


dynamic 


GSM-EFR 




GSM EFR (NOTE 2) 


dynamic 


AMR 


mode-set=7 


TDMA EFR (NOTE 2) 


dynamic 


AMR 


mode-set=4 


PDC EFR (NOTE 2) 


dynamic 


AMR 


mode-set=3 


NOTE 1 : This translation for GSM EFR GSM-EFR) is preferred to the alternative (AMR mode-set=7) if it is supported 
bythelM-MGW. 

NOTE 2: AMR DTX is not compatible with the DTX schemes for any of the codecs in this list. The IM-MGW may 

support these configurations without transcoding by providing interworking between the DTX procedures and 
frame encodings on the bearer interfaces to the BICC CS network and the IM CN subsystem. 



B.2.5.4 Codec parameters for ITU-T codecs 

Table B.4 shows the correspondence between the codec format parameters in the Single Codec information element 
(Clause 11.1.7 of ITU-T Q.765.5 [35]) and the SDP for the ITU-T codecs (Table 4 of RFC 3551 [52], and RFC 3555 
[53]). 

Table B.4: Mapping between Single Codec subfields and SDP parameters for ITU-T codecs 



Single Codec information element 


SDP pa 


/load format parameters 


Codec Type 
subfield 


Codec Name 


Codec Configuration 
subfield (dcba) 


Payload Type 
number 


Encoding 
name 


Other 
Parameters 


00000001 


G.71 1 64 kbit/s A-law 


N/A 


8 


PCMA 




00000010 


G.71 1 64 kbit/s ^i-law 


N/A 





PCMU 




0000001 1 


G.71 1 56 kbit/s A-law 


N/A 


N/A 


N/A 




00000100 


G.71 1 56 kbit/s n-law 


N/A 


N/A 


N/A 




00000101 


G.722 (SB-ADPCM) 


N/A 


9 


G722 




00000110 


G.723.1 


N/A 


4 


G723 


annexa=no 


000001 1 1 


G. 723.1 Annex A 
(silence suppression) 


N/A 


4 


G723 




00001000 


G.726 (ADPCM) 


XXX 1 

xxlx 
xlxx 
Ixxx 


dynamic 
dynamic 
dynamic 
dynamic 


G726-16 
G726-24 
G726-32 
G726-40 




00001001 


G.727 (Embedded 
ADPCM) 


xxxx 


N/A 


N/A 




00001010 


G.728 


111 

(subsets of defined 
rates not supported) 


15 


G728 




00001011 


G.729 (CS-ACELP) 


XX 1 
xlx 
Ixx 


dynamic 

18 

dynamic 


G729D 

G729 

G729E 


annexb=no 
annexb=no 
annexb=no 


00001100 


G.729 Annex B 
(silence suppression) 


XX 1 
xlx 
Ixx 


dynamic 

18 

dynamic 


G729D 

G729 

G729E 




NOTE: An "x" in a bit position of the Codec Configuration subfield indicates a "don't care" value. The SDP payload 

description for each listed codec includes a clock rate of 8000 Hz. TS 26.1 02 [50] only describes the BICC CS 
network framing for the PCM codecs. 
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When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP 
shall include a distinct payload type and any associated parameters for each matching instance of the Codec 
Configuration subfield. For example, G.726 (ADPCM) with Codec Configuration subfield "0101" shall generate SDP 
payload types for G726-32 and G726-16. 

When translating from an SDP payload format specification to the Single Codec information element, each SDP 
payload type should be represented by one matching Single Codec information element. For example, SDP payload 
types for G729 and G729E may generate one Single Codec information element for "G.729 Annex B" with Codec 
Configuration subfield " 110". The G729 and G729E codecs may alternately be represented by two Single Codec 
information elements for "G.729 Annex B" with Codec Configuration subfields "100" and "010", respectively, if it is 
necessary to indicate preference between them. 



B.3 MGCF - IM-MGW interaction during interworking of 
codec negotiation 

B.3.1 Basic IIVI CN subsystem originated session 

This clause shows an example of the interworking of codec negotiation between an IM CN subsystem and a BICC CS 
network during session establishment for an IM CN subsystem originated session. The example applies to BICC 
forward bearer establishment. Similar procedures apply to the other four versions of bearer establishment procedure 
applicable to the BICC CS network. The exchange of codec information is identical in all five cases, but there are 
differences in the sequence of operations associated with bearer establishment within the BICC CS network. 

B.3.1 .1 BICC forward bearer establishment 
B.3. 1.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the CS network side bearer 
establishment. This may happen either before sending the lAM or after receiving the APM message (signal 3 or signal 4 
in figure B.l). In the latter case, the IM-MGW selection may be based on a possibly received MGW-id from the 
succeeding node. 

B.3.1 .1 .2 CS network side bearer establishment 

The MGCF shall either select bearer characteristics or request the IM-MGW to select and provide the bearer 
characteristics for the CS network side bearer connection before sending the lAM. In the latter case the MGCF shall use 
the Prepare Bearer procedure, not shown in figure B.l, to request the IM-MGW to select the bearer characteristics. 
After the succeeding node has provided a bearer address and a binding reference in the APM, the MGCF shall use the 
Establish Bearer procedure to request the IM-MGW to establish a bearer towards the destination CS-MGW. The MGCF 
shall provide the IM-MGW with the bearer address, the binding reference and the bearer characteristics (signal 5 in 
figure B.l). 

B.3.1 .1 .3 IM CN subsystem side session establishment 

When the MGCF receives the Selected Codec from the succeeding serving node in the CS network (signal 4 in figure 
B.l) and selects a codec for use in the IM CN subsystem, the MGCF shall initiate the Reserve IMS Connection Point 
and Configure Remote Resources procedure (signal 7 and 8 in figure B.l). From the received SDP and selected 
configuration data the MGCF: 

Shall send the appropriate remote codec(s), the remote UDP port and the remote IP address to the IM-MGW. 
The remote UDP port and IP address refer to the destination of user plane data sent towards the IM CN 
subsystem. The remote codec(s) are the codec(s) the IM-MGW may select for user plane data sent towards the 
IM CN subsystem. 

Shall indicate to the IM-MGW the appropriate local codec(s) and request a local IP address and UDP port. The 
local IP address and UDP port are used by the IM-MGW to receive user plane data from the IM CN subsystem. 
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The local codec(s) are the codec(s) the IM-MGW may select to receive user plane data from the IM CN 

subsystem. 

If DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 

The IM-MGW 

Shall reply to the MGCF with the selected local codec(s) and the selected remote codec(s) and the selected local 
UDP port and IP address. 

Shall reserve resources for those codec(s). 

The MCGF shall send the local codec(s), UDP port and IP address to the IMS in the Session Progress (signal 9 in figure 
B.l). 

B. 3. 1.1. 4 Through-connection 

During the Prepare Bearer and Establish Bearer procedures, the MGCF shall either use the Change Through-Connection 
procedure to request the IM-MGW to backward through-connect the BICC terminations, or the MGCF shall use this 
procedure to both-way through-connect the BICC termination already on this stage (signal 5 in figure B.l). During the 
Reserve IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to 
request the IM-MGW to backward through-connect the IMS termination (signal 7 in figure B.l). 

When the MGCF receives the BICC:ANM answer indication, it shall request the IM-MGW to both-way through- 
connect the termination using the Change Through-Connection or Change IMS Through-Connection procedures (signal 
20 in figure B.l), unless those terminations are already both-way through-connected. 

B.3.1.1.5 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

B.3.1 .1 .6 Failure handling in IVIGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully the default action by the MGCF is 
to release the session, as described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session as described in clause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

B.3.1 .1 .7 Message sequence chart 

Figure B.l shows the message sequence chart for the IM CN subsystem originating session with BICC forward bearer 
establishment where the selection of IM-MGW is done after receipt of the APM. The MGCF then requests the seizure 
of a CS network side bearer termination and the establishment of the bearer. When the MGCF receives an answer 
indication, it requests the IM-MGW to both-way through-connect the terminations. 
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1. SIP: INVITE 
[supported codec list 1] 



2. SIP : 100 Trying 



Establisin Bearer, Cinange 
Tinrough-Connection = both 



Reserve IMS Connection Point 
and Configure Remote 
Resources, Change IMS 
Through-Connection = backward 



9. SIP :1 83 [selected codec 1 ] 

10. SIP: PRACK 
1 

11.S1P :200 OK (PRACK) 

12. SIP: UPDATE 
13.S1P :200 OK (UPDATE) 



16. SIP :180 Ringing 

17. SIP: PRACK 
18.S1P :200 OK (PRACK) 



22. SJP :200 OK (INVITE) 



23. SIP: ACK 



3. BICC : lAM [supported codec list 2] 



4. BICC : APM [selected codec 2] 



5. H.248 : ADD.req [Context ID = ?, Termination ID = ?] 



6. H.248 : ADD.resp [Context ID = CI, Termination ID = T2] 



7. H.248 : ADD.req [Context ID = CI, Termination ID = ?] 



8. H.248 : ADD.resp [Context ID = CI, Termination ID = T1] 



14. BICC: COT 



15. BICC : ACM 



19. BICC : ANM 



20. H.248 : MOD.req [Context ID = C1, Termination ID = T1] 



21. H.248 : MOD.resp [Context ID = CI, Termination ID = T1] 



Bearer Establishment 



Change IMS 
Through-Connection = both 



CALL IN ACTIVE STATE 



Figure B.1 : Basic IIUI CN Subsystem originating session, BICC forward bearer establishment 

(message sequence chart) 
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B.3.2 Basic CS network originated session 

This clause shows an example of the interworking of codec negotiation between a BICC CS network and an IM CN 
subsystem during session establishment for a BICC CS network originated session. The example applies to BICC 
forward bearer establishment. Similar procedures apply to the other four versions of bearer establishment procedure 
applicable to the BICC CS network. The exchange of codec information is identical in all five cases, but there are 
differences in the sequence of operations associated with bearer establishment within the BICC CS network. 

B.3.2. 1 BICC forward bearer establishment 
B.3.2.1.1 IM-MGW selection 

The MGCF shall select an IM-MGW for the bearer connection before it performs the IM CN subsystem session 
establishment or the CS network side bearer establishment. 

B.3.2.1 .2 IM CN subsystem side termination reservation 

The MGCF shall derive from the codec negotiation procedure one or several appropriate local codec(s) the IM-MGW 
may use to receive user plane data from the IM CN subsystem. The MGCF shall use the Reserve IMS Connection Point 
procedure (signals 2 and 3 in figure B.2/1). Within this procedure, the MGCF shall indicate the local codec(s) and 
request a local IP address and UDP port from the IM-MGW. The local IP address and UDP port are used by the IM- 
MGW to receive user plane data from the IM CN subsystem. If DTMF support together with speech support is required, 
or if the resources for multiple speech codecs shall be reserved at this stage, the reserve value indicator shall be set to 
"true". 

The IM-MGW shall reply to the MGCF with the selected local codec(s) and the selected local IP address and UDP port. 

The MGCF shall send this information in the INVITE (signal 4 in figure B.2/1) to the IM CN subsystem. 

B.3.2.1 .3 IM CN subsystem side session establishment 

The MGCF shall use the Configure IMS Resources procedure (signals 7 and 8 in figure B.2/1) to provide configuration 
data (derived from SDP received in signal 6 in figure B.2/1 and the codec negotiation procedure) to the IM-MGW as 
detailed below: 

The MGCF shall indicate the remote IP address and UDP port, i.e. the destination IP address and UDP port for 
data sent in the user plane towards the IM CN subsystem. 

The MGCF shall indicate the remote codec(s), i.e. the speech codec(s) for data sent in the user plane towards the 
IM CN subsystem. 

The MGCF may indicate the local codec(s) and the local IP address and UDP port. The MGCF shall indicate the 
local codec(s) if a change is required. 

IF DTMF support together with speech support is required, the reserve value indicator shall be set to "true". 



The IM-MGW shall reply with the selected remote codec(s) and reserve resources for these codec(s). If local codec(s) 
were received, the IM-MGW shall also reply with the selected local codec(s) and reserve the corresponding resources. 

If the selected local codec(s) differ from the codec(s) received in the SDP of signal 6 in figure B.2/1, the MGCF shall 
send the local reserved codec(s), and the local IP address and UDP port in the PRACK (signal 9 in figure B.2/1) to the 
IMS. 

B.3.2.1 .4 CS network side bearer establishment 

The MGCF shall request the IM-MGW to prepare for the CS network side bearer establishment using the Prepare 
Bearer procedure (signals 1 1 and 12 in figure B.2/1). Within this procedure, the MGCF shall request the IM-MGW to 
provide a bearer address, a binding reference and optionally notify when the bearer is established. The MGCF shall also 
provide the IM-MGW with the bearer characteristics determined by the codec negotiation procedure. After the IM- 
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MGW has replied with the bearer address and the binding reference, the MGCF provides the APM message (signal 13 
in figure B.2/1) to the preceding node. The MGCF may also provide the IM-MGW-id in the APM message. 

B.3.2.1 .5 Called party alerting 

The MGCF shall request the IM-MGW to provide an awaiting answer indication (ringing tone) to the calling party 
using the Send Tone procedure (signals 21 and 22 in figure B.2/1) , when the first of the following conditions is 
satisfied: 

the MGCF receives the first 1 80 Ringing message 

Timer T i/wi expires 

Timer T i/w2 expires 



B.3.2.1 .6 Called party answer 

When the MGCF receives a 200 OK message (signal 23 in figure B.2/2), it shall request the IM-MGW to stop providing 
the ringing tone to the calling party using the Stop Tone procedure (signals 26 and 27 in figure B.2/2). 

B.3.2.1. 7 Through-Connection 

During the Prepare Bearer procedure, the MGCF shall either use the Change Through-Connection procedure to request 
the IM-MGW to backward through-connect the BICC termination, or the MGCF shall use this procedure to both-way 
through-connect the BICC termination already on this stage (signals 1 1 and 12 in figure B.2/1). During the Reserve 
IMS Connection Point procedure, the MGCF shall use the Change IMS Through-Connection procedure to request the 
IM-MGW to backward through-connect the IMS termination (signals 2 and 3 in figure B.2/1). 

When the MGCF receives the SIP 200 OK(INVITE) (signal 23 in figure B.2/2), it requests the IM-MGW to both-way 
through-connect the terminations using the Change IMS Through-Connection or Change Through-Connection 
procedures (signals 28 and 29 in figure B.2/2), unless those terminations are already both-way through-connected. 



B.3.2.1. 8 Codec handling 

The IM-MGW may include a speech transcoder based upon the speech coding information provided to each 
termination. 

B.3.2.1 .9 Failure handling in MGCF 

If any procedure between the MGCF and the IM-MGW is not completed successfully, the default action by the MGCF 
is to release the session as described in clause 9.2.6. If the MGCF receives a Bearer Released procedure from the IM- 
MGW the default action by the MGCF is to release the session, as described in clause 9.2.7. 

NOTE: As an implementation option the MGCF may also decide for example to only release the resources in the 
IM-MGW that caused the failure, possibly select a new IM-MGW for the connection and continue the 
call establishment using new resources in the selected IM-MGW but such handling is outside of the scope 
of the present document. 

B.3.2.1 .10 Message sequence chart 

Figures B.2/1 and B.2/2 show the message sequence chart for the CS network originating session with BICC forward 
bearer establishment. 
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MGCF 



1 . BICC : lAM [supported codec list 1] 



Configure IMS Resources 



2. H.248 : ADD.req [Context ID = ?, Termination ID=?] 



3. H.248 : ADD.resp [Context ID = CI , Termination ID = T1] 



7. H.248 : MOD.req Context ID = CI .Termination ID = T1] 



8. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



1 1 . H.248 : ADD.req [Context ID = C1 , Termination ID = ?] 



12. H.248 : ADD.resp [Context ID = CI , Termination ID = 12] 



13. BICC : APM [selected codec 1, available codec list 1] 



Bearer Establishment 



14. BICC: COT 



20. BICC : ACM 



21 . H.248 : MOD.req [Context ID = CI , Termination ID = T2] 



22. H.248 : MOD.resp [Context ID = CI , Termination ID = T2] 



Reserve IMS Connection Point, 
Change IMS Tlirougli- 
Connection = backward 

4. SIP: INVITE 
[supported codec list 2] 



5. SIP: 100 Trying 



6. SIP:183 
[available codec list 2] 



9. S!P: PRACK 
[selected codec 2] 



10.S!P:200OK (PRACK) 
[selected codec 2] 



Prepare Bearer, 
Change Througli- 
Connection= both 



15. SIP: UPDATE 



16. S!P:200 OK (UPDATE) 

17. S!P:180 Ringing 

18. SIP: PRACK 



19.S!P:200OK(PRACK) 



Send Tone 



Figure B.2/1 : Basic CS Network Originating Session, BICC forward bearer establisliment 

(message sequence chart) 
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24. H.248 : MOD.req [Context ID=C1 , Termination ID : 
T2] 



25. H.248 : MOD.resp [Context ID = C1, Termination ID = T2] 



26. H.248 : MOD.req [Context ID=C1 , Termination ID : 
T1] 



27. H.248 : MOD.resp [Context ID = CI, Termination ID = T1] 



28. BICC: ANM 



23. S!P:200 OK (INVITE) 



Stop Tone 



Change IMS 
Through-Connection = both 



29. SIP: ACK 



CALL IN ACTIVE STATE 



Figure B.2/2: Basic CS Network Originating Session, BICC forward bearer establishment 

(message sequence chart continued) 
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B.3.3 CS network initiated mid-call codec negotiation 

Figure B.3 shows the CS network initiated mid-call codec negotiation procedure interworking with the IM CN 
subsystem. When the MGCF selects the codecs for the CS network and the IM CN subsystem (after signal 3 in figure 
B.3), the MGCF shall modify the CS network termination and the IM CN subsystem termination on the IM-MGW to 
conform to the newly selected configuration data on the two interfaces. The MGCF may perform bearer operations (not 
shown) at the IM-MGW before interworking the initial codec modification request (signal 2 in figure B.3) to determine 
new connection information, if necessary, or to verify resource availability. 



IM-MGW 



MGCF 



1 . BICC : APM [supported codec list 1] 



Configure IMS Resources 



Modify Bearer Cfiaracteristics 



4. H.248 : MOD.req Context ID = C1, Termination ID = T1] 



5. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



6. H.248 : MOD.req [Context ID = CI , Termination ID = 12] 



7. H.248 : MOD.resp [Context ID = CI , Termination ID = T2] 



9. BICC : APM [selected codec 1] 



1 0. BICC : APM [action = successful codec modification] 



2. SIP: re-INVITE 
[supported codec list 2] 



3. S!P:200 OK (INVITE) 
[selected codec 2] 



8. S!P: ACK 



Figure B.3: CS network initiated mid-call codec negotiation 
(message sequence chart) 
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B.3.4 IM CN subsystem initiated mid-call codec negotiation 

Figure B.4 shows the IM CN subsystem initiated mid-call codec negotiation procedure interworking with a BICC CS 
network. When the MGCF selects the codecs for the CS network and the IM CN subsystem (after signal 3 in figure 
B.4), the MGCF shall modify the CS network termination and the IM CN subsystem termination on the IM-MGW to 
conform to the newly selected configuration data on the two interfaces. The MGCF may perform bearer operations (not 
shown) at the IM-MGW before interworking the initial codec modification request (signal 2 in figure B.3) to determine 
new connection information, if necessary, or to verify resource availability. The MGCF may also perform bearer 
operations (not shown) at the IM-MGW after sending the final APM (signal 8 in figure B.4) to modify transport 
bandwidth, if necessary. 



IM-MGW 



2. BICC : APM [supported codec list 2] 



3. BICC : APM [supported codec list 2] 



Configure IMS Resources 



Modify Bearer Characteristics 



4. H.248 : MOD.req Context ID = C1 Termination ID = T1] 



5. H.248 : MOD.resp [Context ID = CI , Termination ID = T1 ] 



6. H.248 : MOD.req [Context ID = CI , Termination ID = T2] 



7. H.248 : MOD.resp [Context ID = CI , Termination ID = 12] 



8. BICC : APM [action = successful codec modification] 



1.SIP:re-INVITE 
[supported codec list 1] 



9. S!P:200 OK (INVITE) 
[selected codec 1] 



10. SIP:ACK 



Figure B.4: IM CN subsystem initiated mid-call codec negotiation 
(message sequence chart) 
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